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EXECUTIVE  SUMMARY 


Business  enterprises  must  team  to  survive  in  a  rapkJiy  changing  and  highly  competitive 
environment.  The  Naval  Surface  Wartere  Center.  Dahlgren  Division  (NSWCOD)  is  no  different 
in  this  regard  than  any  oommerdai  enterprise.  Department  of  Defense  (DoD)  consolidation  and 
reaiignment  initiatives  wiil  iikely  introduce  more  change  to  NSWCDD  than  at  any  time  in  recent 
history.  DoD  will  probably  face  large  funding  cuts  as  a  result  of  changes  in  Europe  and  Asia. 
NSWCDD  must  be  able  to  manage  that  change  and  still  meet  the  demand  for  high-quality  products 
and  services  at  competitive  cost.  NSWCDD  is  essentiaily  a  knowledge-based  industry,  and 
therefore  depends  upon  a  flexible  and  responsive  information  infrastructure  to  accompiish  its 
mission.  The  more  change  that  occurs  in  our  environment,  the  more  flexible  that 
infrastructure  must  be. 

The  first  step  in  effecting  a  flexible  infrastructure  was  to  identity  where  change  might 
be  benefidai  by  anaiyzing  what  information  and  functions  are  needed  and  how  they  should  relate 
for  NSWCDD  to  operate  as  a  Defense  Business  Operating  Fund  (DBOF)-funded  R&D  organization. 
This  analysis  needed  to  be  performed  without  regard  to  current  processes  or  organizational 
structures.  Information  Strategy  Pianning  (iSP)  is  the  top-levei  identification  of  how  and 
what  we  coukf  do,  what  types  of  information  are  required,  and  how  it  makes  sense  to  group  them 
for  optimai  sharing  of  information  and  minimal  aoss-functionality. 

The  purpose  of  this  document  is  to  report  on  the  findings  and  recommendations  arising 
from  the  ISP  task.  ISP  provides  the  link  between  the  business  strategy  pianning  and  the 
development  of  information  systems  and  architectures.  iSP  is  most  effective  when  the  whole 
enterprise  is  induded  in  the  analysis.  The  NSWCDD  iSP  project  induded  NSWCDD  in  its 
entirety  and  did  not  iimit  its  analysis  to  business  functions  of  the  support  organizations,  but 
also  induded  functions  that  relate  to  the  l)usiness”  of  accomplishing  the  technical  mission  of 
NSWCDD.  it  identifies  strategies  for  satisfying  the  complete  range  of  information  needs;  i.e., 
not  just  business  systems  but  also  information  needed  in  the  generation  of  NSWCDD  products  and 
services.  It  provides  a  basis  for  delivering  systems  that  are  retevant  to  NSWCDD  and  which  are 
targeted  at  supporting  the  principle  business  directions. 

NSWCDD  lies  in  a  chain  of  command  which  is  also  pursuing  the  streamiining  and 
enhandng  of  its  business  processes.  The  DoD,  DoN,  and  NAVSEA  infonnation  Resource 
Management  (iRM)  strategies  will  affect  the  f^WCDD  pursuit  of  its  IRM  strategies,  as  laid  out 
in  this  document.  Each  of  our  parent  organizations  are  moving  ahead  in  efforts  to  change 
functional  processes  and  reexamine  the  IRM  rde  within  our  communities.  The  ISP  incorporates 
the  DoD,  Department  of  Navy  (DoN).  and  Naval  Sea  Systems  Command  (NAVSEA)  visions  for 
improved  business  processing  and  is  consistent  with  the  direction  being  taken  by  these 
organizattons  at  this  time.  The  ISP  and  foitow-on  work  of  analyzing  our  business  areas  will 
position  us  to  respond  correctly  and  rapidly  to  the  work  going  on  above  us  in  the  chain  of 
command. 
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The  four  principal  products  of  ISP  are  (1)  the  Information  Architecture,  (2)  the 
Business  Systems  Architecture,  (3)  Technicai  Architecture,  and  (4)  the  strategy  for 
information  systems  development.  The  archKectures  constitute  a  model  of  the  business.  They 
can  be  used  to  suggest  and  evaluate  a  wide  range  of  possible  change,  including  organizational 
structure  change,  process  improvement,  and  change  of  business  rules. 

The  Information  Architecture  consists  of  a  data  model  and  a  function  modei  that  represent 
the  categories  of  data  that  are  important  to  the  enterprise  and  the  high-level  functions  that  use 
those  data.  Analyzing  the  interactions:  i.e.,  aeate,  read,  update,  and  delete,  that  exist  between 
functions  and  data  yields  a  Business  Systems  Architecture.  The  Business  Systems  Architecture 
is  comprised  of  logical  data  stores  and  business  systems.  At  the  planning  stage,  the  Technical 
Architecture  consists  of  a  model  of  the  types  of  hardware,  software,  and  communications 
technology  that  will  be  required  to  support  the  systems  architecture. 

We  identified  63  processes  from  a  functionai  decomposition  of  NSWCDD  and  48  data 
entity  types.  By  analyzing  the  interactions  between  processes,  between  data  entity  types  and 
between  processes  and  data  entity  types,  we  re-grouped  the  processes  and  data  entity  types.  The 
processes  are  grouped  into  25  business  systems  (Figure  4-6),  which  are  further  grouped  into 
10  business  areas  (Figure  4-8).  The  data  entity  types  are  grouped  into  thirty-three  data 
stores  (Figure  4-5),  and  then  the  data  stores  are  associated  with  the  business  area  that  creates 
their  data.  The  future  work  involves  analyzing  the  individual  business  areas  and  then 
developing  the  required  systems  and  dataltases  to  carry  out  the  needed  functionality.  The 
systems  developed  to  support  any  business  area  need  not  be  automated,  but  may  only  be  an 
improved  manual  or  semi-automated  system. 

The  ISP  has  specified  a  very  large,  complex  and  highly  interrelated  model  to  be  used  for 
information  technology  system  development.  The  model  reflects  the  complexity  and  flexibility 
under  which  NSWCDD  operates.  The  information  strategy  should  be  driven  by  business  needs. 

To  meet  the  business  needs  will  require  that  strategies  also  be  pursued  to  assess  and  implement 
a  technologically  effective  infrastructure.  The  largest  business  drivers  are: 

1 .  need  to  lower  NSWCDD  operating  costs 

2.  large  administrative  burden  on  line  management  and  technical  staff 

3.  non-compliant  financial  management  system 

4.  DoD  Cor|x>rate  Information  Management  (CIM)  mandated  systems  looming 

5.  multiple  sites  needing  to  share  information 

6 .  lack  of  coordinated  data 

7.  less  functionality  in  offloe  automation  than  desirable 

These  drivers  combine  in  rflfferent  ways  to  direct  which  business  areas  should  be  analyzed  first 
and  which  information  organization  strategies  are  required  immediately.  The  strategies  are 
fairty  risky  and  wfll  tax  the  abilities  of  the  Systems  Division  to  proceed  on  such  a  broad  front. 
The  political  situation  and  environment  of  NSWCDD  and  the  NSWC  Information  Command  and 
Control  System  (NICCS)  Program,  however,  drives  us  to  this  course  of  action.  There  is  a  risk 
of  sipped  deadflnw.  If  not  too  delayed,  the  damage  may  not  be  too  bad  as  the  CIM  and  NAVSEA 
efforts  may  also  not  meet  their  schedules.  CIM  is  behind  its  objectives  at  tois  time  because  they 


NSWCDD/TR-92/47 


were  aiy>  pursuing  a  very  aggressive  course  of  action.  There  is  a  large  risk  of  funding  being  cut 
to  the  program.  The  result  of  deep  cuts  would  be  the  inability  to  carry  out  these  directions  and 
the  consequential  inability  of  NSWCDD  to  be  relieved  of  the  severe  productivity  deterrents 
represented  by  the  drivers. 

We  will  follow  a  focused  effort  in  the  Business  System  area.  A  focused  effort  is  needed 
,  because  of  the  extreme  pressure  of  drivers  (1),  (2).  (3)  and  (4).  The  focused  effort  will 

include  the  Financial  Management  area  and  that  part  of  the  Planning  &  Review  area  that  involves 
financial  data.  This  is  a  risky  direction  to  take  but  is  necessary  because  of  time  constraints. 
NSWCDD  must  be  able  to  define  its  information  and  process  requirements  in  this  area  before 
CIM  furnishes  financial  systems  to  do  the  finandaf  transaction  processing.  Without  the 
NSWCDD  requirements,  we  would  be  unable  to  effectively  respond  to  and  implement  those 
systems.  If  CIM  does  not  prorfoce  a  financial  system,  we  must  still  pursue  this  direction  because 
of  the  non-compliant  status  of  the  current  firutnciai  management  system. 

We  will  move  out  of  the  normal  Information  Engineering  methodology  and  pursue  the 
development  of  the  Corporate  Database  (CDB)  in  parallel  with  the  focused  effort.  The  CDB  is  the 
logical  database  containing  ail  of  the  business  data  of  NSWCDD.  Normally,  the  analysis  of  the 
Business  Areas  defines  the  data  needs.  We  will  attempt  to  build  preliminary  databases 
comprised  of  data  elements  already  found  in  some  existing  systems.  We  are  taking  this  tack 
because  of  drivers  (1),  (2),  (4)  and  (6).  This  effort  will  also  focus  on  financial  data  initially. 
The  CDB  effort  will  be  involved  in  more  than  the  data  requirements  of  the  Financial  Management 
Business  Area  Analysis.  As  will  be  seen  by  the  diagrams  and  charts  in  Chapter  4,  every 
business  area  updates  or  reads  data  from  many  other  business  areas.  In  particular,  data  stores 
from  the  Organiiation  Management  and  Product  Development  business  areas  will  need  to  have 
skeleton  databases  developed.  The  principle  data  requirements  for  Organization  Management 
were  automated  several  years  ago.  The  Center  Human  Resource  Information  System  (CHRIS) 
was  developed  for  the  Human  Resource  Department  and  is  based  on  relational  database 
technology.  It  will  form  the  basis  for  the  supply  of  personnel  and  organizational  information 
needed  for  the  Financial  Management  business  area.  Data  extract  programs  will  need  to  be 
developed  between  CHRIS  and  the  CDB.  Of  course,  eventually,  CHRIS  databases  will  become  a 
part  of  the  CDB.  Skeleton  data  bases  for  the  other  data  needs  wiN  be  defined  and  populated, 
pending  proper  definition  at  a  later  time.  Technk^es  will  also  have  to  be  develop  for  the 
population  and  low-level  maintenance  of  these  skeleton  databases. 

Moving  into  a  controlied  information  environment  requires  the  establishment  of  a  data 
administration  function.  This  is  the  principle  infrastructure  media  for  effecting  the  proper 
environment  for  information  management  and  the  coordinated  development  of  information 
systems.  In  particular,  drivers  (1),  (2),  (4),  (5).  and  (6)  strongiy  support  this  strategy. 
Data  administration  deals  with  the  management  and  control  of  data  as  an  enterprise  asset.  It 
includes  strategic  information  planrting,  data  modeling,  logicai  database  design,  and  the 
establishment  of  standards,  policies,  and  procedures  for  the  care  and  feeding  of  data;  e.g., 

4  ownership,  security,  privacy,  quality,  and  integrity.  Data  administration  leads  to  Improved 

NSWCDD  profitability.  We  wW  establish  a  Data  Administratton  (DA)  function  at  NSWCDD.  The 
functions  descrbed  wtthin  the  scope  of  DA  at  NSWCDD  wW  include:  DA  representation,  policies, 
guidelines  and  standards;  DA  partnerships;  data  planning;  the  data  repository  and  configuration 
management;  compiianoe  with  DA  policies  and  standards;  and  OA  measurement  of  program 

•  *  s 
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effectiveness.  These  functions  are  consistent  with  the  [}oD  and  DoN  DA  guideiines,  directives, 
and  implementation  procedures. 

The  establishment  of  the  DA  function  will  not  solve  the  Information  problems  of  NSWCDD 
by  itself.  DA  is  a  piece  of  the  bigger  infrastnicture  and  senrices  needed  to  manage  information 
at  NSWCDD.  The  proper  management  and  use  of  infonnation  at  NSWCDD  would  produce  the 
biggest  benefit  to  NSWCDD  ••  more  than  financial  management.  NSWCDD  as  an  R&D  center  is 
in  the  knowledge  business.  We  take  information  and  transform  it  into  senrices  or  products. 
Being  able  to  access  and  use  information  effectiveiy  is  the  key,  therefore,  not  only  to  foe  proper 
functioning  of  our  business  processes  but  also  to  our  producing  products  and  services.  Lack  of 
automation  support  for  collaboration  inhibits  our  Ability  to  make  teams  of  people  across  sites. 
Lack  of  automation  support  for  the  sunrey  of  outside  information  on  developments  in  our  areas 
of  business- increase  the  time  it  takes  our  persormel  to  stay  abreast  of  their  technical  fields  and 
increase  the  risk  of  missing  a  vital  piece  of  information  that  might  make  a  breakthrough 
possible.  Lack  of  coordinated  data  to  respond  to  outside  fire  drills  drains  foe  time  of  our  line 
managers  from  technical  leadership  efforts.  The  list  is  quite  long.  Defining  good  information 
management  is  critical  to  the  solutions  for  drivers  (1),  (2),  (5),  (6),  and  (7). 

The  analysis  of  the  Information  Management  (IM)  business  area  is  foe  most  difficult 
technically  of  alt  of  the  business  areas  and  is  tigh^  interwoven  with  all  other  work  stemming 
from  foe  ISP.  The  IM  business  area  will  be  difficult  to  perform  because  its  analysis  does  not 
completely  follow  foe  normal  Information  Engineering  methods  because  its  goal  is  more  than  the 
definition  and  development  of  systems.  Part  of  foe  IM  work  is  the  identification  of  tools  and 
technologies  to  be  employed  in  the  care  and  feeding  of  infonnation  identified  in  other  business 
areas.  However,  foe  identification  of  these  tools  and  fechnologies  will  help  determine  the 
direction  pursued  in  foe  other  efforts  -  even  to  foe  extent  of  suggesting  information  that  could 
be  created.  We  are  left  with  a  circular  problem  and  a  technology  that  moves  extremely  rapidly. 
The  IM  business  area  enables  the  other  business  areas  to  proceed  in  a  coordinated  and  effective 
manner.  The  outcome  of  this  effort  will  define  foe  infrastructure  required  for  the  life  cyde  of 
all  the  systems  to  be  developed  and  also  wM  define  services  and  functions  needed  to  handle  the 
various  types  of  information  used  at  NSWCDD  ~  regardtoss  of  foe  form.  This  latter  outcome 
provides  the  rationale  for  making  decisfons  About  foe  technical  architecture  and  permits  foe 
evaluation  of  new  technologies'  applicAbiMy  to  NSWCDD  problems. 

NSWCDD  is  in  the  process  of  estAblishing  a  Total  Quality  ManagemenVLeadership  (TQM) 
environment.  This  change  in  organizational  and  mangeriai  philosophy  will  have  a  major  impact 
on  the  design  and  implementation  of  biformalion  systems.  Every  other  business  change  that  has 
occurred  in  foe  past  has  been  designed  to  move  complexity  out  of  foe  work  environment  and  to 
move  information  handNng  up  the  organization  ladder.  Now,  we  are  giving  decision  making 
responsfoHity  to  the  lowest  possfoie  level.  To  be  able  to  make  decisions,  the  employees  of 
NSWCDD  wM  need  information.  Three  things  wW  affect  foe  information  processing  scenario. 
First,  foe  type  of  information  will  change  at  different  levels  from  what  it  has  been  in  the  past. 

In  pwticular,  for  TQM  to  work,  each  employee  neecfe  to  know  foe  vision,  direction,  and 
evaluation  criteria  that  combine  to  ten  him  or  her  what  constitutes  success  for  the  organization. 
Without  this  information,  the  employee  can  not  donsistentiy  make  proper  decisions;  i.e.. 
decisions  that  wM  nwve  the  organization  on  towards  improved  productivity  and  client 
satisfaction.  TradWonaRy  such  Information  has  been  given  selectively  to  managers  at  different 
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levels.  Now  the  field  Is  wide  open.  Second,  since  the  field  is  wide  open  and  since  decisions  will 
be  being  made  by  more  people,  the  sources  of  information  wiil  be  much  more  widely  dispersed. 
At  NSWCDD  there  is  great  physical  dstance  between  major  locations  and  physical  distances 
between  people  who  need  to  share  information  at  a  particular  site.  The  availability 
requirements  and  timeliness  requirements  still  remain,  and  need  to  satisfy  many  nwre  people 
who  are  geographically  dispersed.  These  needs  should  affect  technical  design  decisions;  i.e.. 
move  away  from  large  central  databases  because  of  potential  reliability  and  performance 
problems.  Third.  TQM  and  Information  Engineering  (IE)  have  a  great  overlap  in  purpose  and 
process.  NSWCDD  will  need  to  mesh  its  efforts  in  these  two  areas. 

The  strategy  above  has  been  fonnulated  for  the  first  steps.  When  these  efforts  are 
completed,  the  next  steps  will  be  determined.  The  volatility  of  the  environment  makes  setting 
direction  for  the  longer  course  ludicrous.  The  ordering  of  these  and  future  steps  should  be  based 
on  the  most  important  needs  of  NSWCDD  and  will  be  reviewed  as  events  cause  NSWCDD  to  re¬ 
order  its  priorities.  We  will  continue  to  pursue  the  course  that  makes  best  sense  for  NSWCDD 
while  adjusting  to  external  drivers. 
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FOREWORD 


The  Information  Strategy  Plan  contained  in  this  report  was  produced  by  the  Systems 
Division  of  the  Engineering  and  information  Systems  Department  supported  by  personnel  from 
many  of  the  NSWCDD  technical  and  support  departments. 

The  main  body  of  the  report  was  written  by  W.R.  Burrell  and  C.B.  Wilson  of  the  Systems 
Division  with  contributions  from  W.R.  Cushing,  D.E.  Tabler  and  D.L.  Becker.  The  Information 
Engineering  architecture  details  were  modeled  by  a  core  team  of  Systems  Division  personnel 
using  information  supplied  by  a  reference  team  of  NSWCDD  employees.  The  effort  used  a 
Knowledgeware,  Inc.  Information  Engineering  Workbench  (lEW)  CASE  tool  on  a  25  MHz  80386- 
based  personal  computer  to  assist  in  the  modeling.  The  James  Martin  Associates  Information 
Engineering  methodology  was  followed. 

The  E50  core  team  included:  W.R.  Burrell,  M.L  Hye-Knudsen,  M.A.  Reese  and  K.L. 
Truslow.  The  NSWCDD  reference  team  included;  FCCM  D.S.  Reedal  (C4);  C.L.  Berkey  (D2);  R.D. 
Wiseman  and  R.M.  Pollock  (E);  W.  Innis  (G);  LC.  Loeffler  (K);  H.O.  Williams,  B.S.  Goldman  and 
LW.  Dabbs  (M);  W.J.  Ferreira  (P);  K.F.  Caudle  and  C.W.  Larson  (R);  J.L.  Schmidt  (S);  R.C. 
One  (U);  and  E.N.  Resio  (W).  Advisors  used  included;  C.L.  Burleson  and  C.B.  Wilson  (E50);  D.C. 
Gardiner  (E04);  James  Martin  Associates;  Knowledgeware,  Inc.;  and  the  Fleet  Material  Support 
Office  (FMSO). 

If  you  have  any  questions  or  comments  on  the  Information  Strategy  Plan  outlined  in  this 
report  or  the  process  used,  please  contact  the  Systems  Division  on  (703)  663-1827.  The 
detailed  definitions  of  functions  and  data  entities  are  not  included  in  this  report  but  are 
available. 


Approved  by; 

R.T.  RYLAND,JR.,Head 
Engineering  and  Information 
Systems  Department 
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ABSTRACT 


An  enterprise-wide  Information  Strategy  Plan  (ISP)  and  model  was  developed  for  a 
5000  person.  Navy  R&O  center,  spanning  four  geographically  dispersed  sites.  The  ISP  included 
all  of  NSWCDD  as  it  was  constituted  at  that  time  before  the  consolidation;  i.e.,  the  ISP  does  not 
include  the  Coastal  Systems  Station.  The  ISP  was  not  restricted  to  the  support  areas  but 
included  the  technical  mission  of  the  center.  The  ISP  provides  a  basis  for  delivering  systems 
that  are  relevant  to  the  enterprise  and  that  are  target^  at  supporting  the  principle  business 
directions.  The  work  analyzed  the  total  business  goals  for  NSWCDD  with  respect  to  how 
information  technology  does  or  could  enhance  its  abilities  to  meet  its  goals.  Using  teams  of 
people  representing  many  viewpoints  and  levels  within  in  the  enterprise,  models  were 
developed  showing  what  information  and  functions  NSWCDD  needs  to  perfonn  its  business.  A 
data  model  consisting  of  48  entity  types  and  a  function  model  consisting  of  63  processes  were 
developed.  These  two  models  were  combined  using  affinity  analysis  to  generate  10  groups  of 
entity-types  and  processes,  called  business  areas.  The  groupings  are  without  regard  to  current 
organizational  structure.  A  technical  architecture  was  developed  to  describe  approaches  to  be 
used  to  implement  the  business  areas  in  the  future.  The  report  also  describes  the  methodology 
used  to  generate  the  ISP.  The  approach  was  based  on  a  form  of  Information  Engineering,  assisted 
by  automated  Computer-Aided  Software  Engineering  (CASE)  tools. 
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CHAPTER  1 
INTRODUCTION 


Business  enterprises  must  learn  to  survive  in  a  rapidly  changing  and  highly  competitive 
environment.  The  Dahlgren  Division  of  the  Naval  Surface  Warfare  Center  (NSWCDD)  is  no 
different  in  this  regard  than  any  commercial  enterprise.  Dod  consolidation  and  realignment 
initiatives  will  likely  introduce  more  change  to  NSWCDD  than  at  any  time  in  recent  history. 
NSWCDD  must  be  able  to  manage  that  change  and  still  meet  the  demand  for  high-quality  products 
and  services  at  competitive  cost.  NSWCDD  is  essentially  a  knowledge-based  industry,  and 
therefore  depends  upon  a  flexible  and  responsive  information  infrastructure  to  accomplish  its 
mission.  The  more  change  that  occurs  in  our  environment,  the  more  flexible  that 
infrastructure  must  be. 

The  NSWC  Information  Command  and  Control  System  (NICCS)  was  established  to  satisfy 
identified,  but  unsatisfied,  operational  needs  at  NSWCDD.  In  particular,  the  goal  of  NICCS  is  to 
expedite  NSWCDD  business  operations  and  enat^  NSWCDD  to  be  more  responsive  and 
competitive  as  an  R&D  center.  For  NICCS  to  be  a  successful  program,  it  was  determined  that  it 
should  enable  NSWCDD  to  change  the  way  it  operates  by  identifying  where  such  changes  could 
occur  and  then  providing  automation  support,  when  required,  to  implement  those  changes.  The 
first  step  in  effecting  this  strategy  was  to  identify  where  change  might  be  beneficial  by 
analyzing  what  information  and  functions  are  needed  and  how  they  should  relate  for  NSWCDD  to 
operate  as  a  DBOF-funded  R&D  organization.  This  analysis  needed  to  be  performed  without 
regard  to  current  processes  or  organizational  structures.  The  ISP  is  the  top-level 
identification  of  how  and  what  we  could  do,  what  types  of  information  are  required,  and  how  it 
makes  sense  to  group  them  for  optimal  sharing  of  information  and  minimal  cross-functionality. 
From  this  beginning,  NSWCDD  through  the  NICCS  program  can  continue  the  analysis  of  each 
grouping  to  define  better  processes  and  the  propt '  o^anizational  structures  to  perform  the  re¬ 
defined  processes. 

The  purpose  of  this  document  is  to  report  on  the  findings  and  recommendations  arising 
from  the  ISP  task.  ISP  provides  the  link  between  the  business  strategy  planning  and  the 
develr^ment  of  information  systems  and  architectures.  It  identifies  strategies  for  satisfying  the 
complete  range  of  information  needs  for  NSWCDD;  i.e.,  not  just  business  systems  but  also 
information  needed  in  the  generation  of  NSWCDD  products  and  services.  It  provides  a  basis  for 
delivering  systems  that  are  relevant  to  NSWCDD  and  targeted  at  supporting  the  principle 
business  directions. 

NSWCDD  lies  in  a  chain  of  command  whidt  is  also  pursuing  the  streamlining  and 
enhancing  of  its  business  processes.  The  DoD,  DoN,  and  NAVSEA  Information  Resource 
Management  (IRM)  strategies  will  affect  the  NSWCDD  pursuit  of  its  IRM  strategies,  as  laid  out 
in  this  document.  Each  of  our  parent  organizations  are  moving  ahead  in  efforts  to  change 
functional  processes  and  reexamine  the  IRM  rote  within  our  communities.  The  ISP  incorporates 
the  DoD,  DoN,  and  NAVSEA  visions  for  improved  business  processing  and  is  consistent  wi^  the 
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direction  being  taken  by  these  organizations  at  this  time.  The  iSP  and  foiiow-on  work  of 
analyzing  our  business  areas  will  position  us  to  respond  correctly  and  rapidly  to  the  work  going 
on  above  us  in  the  chain  of  commaiid. 

ISP  is  the  initial  stage  of  an  analysis  process  (known  as  Information  Engineering).  The 
process  strives  to  ensure  that  an  enterprise's  infonnation  infrastructure  supports  the  present 
business  needs  and  is  flexible  enough  to  meet  future  needs  as  they  arise.  By  analyzing  the 
enterprise  as  a  system  in  its  own  right,  a  baseline  of  requirements  can  be  established  and  used 
as  a  mechanism  for  managing  change. 

Perhaps  an  analogy  will  bring  this  idea  into  focus.  Developing  a  complex  product 
rer^ires  detailed  engineering  spedfications  to  be  produced.  Buildings,  airplanes,  ships, 
missiles,  all  have  to  be  specified  precisely  enough  to  guarantee  that  the  customer's 
requirements  will  be  met  and  that  the  level  of  risk  associated  with  producing  the  product  will  be 
aocept£A)le.  These  specifications  are  dso  used  k)  manage  changes  to  these  products  once  they 
have  been  developed.  No  responsible  electrician  vrouid  install  a  new  power  outlet  without 
inspecting  the  building  wiring  diagram  first.  No  responsible  engineer  would  redesign  a 
component  of  a  weapon  system  without  assessing  the  impact  of  that  change  on  the  total  system. 

ISP  is  the  first  step  toward  establishing  this  specification  baseline  for  NSWCDD's 
information  systems  and  for  NSWCDO  itself.  The  following  chapters  of  this  document  will 
address  the  components  of  the  specification  baselfoe  that  resulted  from  analysis  of  NSWCDD 
from  the  perspectives  of  its  information  environment,  its  business  systems  environment,  and 
its  information  technology  environment.  We  will  discuss  these  environments  in  terms  of  their 
current  state  and  the  state  to  which  they  should  evolve  to  better  support  the  business  of 
NSWCDO. 


Fundamental  to  the  concept  of  providing  a  flexible  information  infrastructure  is  the 
recognition  that  data  is  the  most  stable  component  of  any  business.  To  put  this  in  perspective, 
consider  Figure  1-1,  which  compares  the  relative  frequency  of  change  that  can  be  exp^ed  for 
data,  functions,  processes,  and  procedures. 


high 
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Figure  1-1 .  Relative  Frequency  of  Change  of  Business  Objects 
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Business  processes  and  procedures  are  manifestations  of  the  rules  that  govern  operation 
of  the  business.  These  rules,  in  turn,  are  based  on  interpretations  of  current  policy  as  dictated 
from  within  the  organization  or  from  some  external  authority.  Because  of  the  inherent 
likelihood  that  business  rules  will  change  over  time,  information  systems  designed  to  automate 
processes  and  procedures  are  naturally  subject  to  high  rates  of  change  and  therefore  require  a 
great  deal  of  maintenance  over  their  life  cycle.  On  the  other  hand,  systems  whose  design  is  based 
on  the  business's  data  requirements  are  more  flexible,  are  changed  less  frequently,  and  need 
less  maintenance  over  time.  To  evolve  to  this  kind  of  environment,  data  must  be  recognized  as  a 
resource  of  the  enterprise.  Data  must  be  defined  in  terms  of  its  role  in  the  business  and  must  be 
independent  of  the  perspective  of  any  particuiar  application.  ISP  recognizes  data  as  an 
important  resource  of  the  enterprise  and  lays  the  foundation  for  the  effective  management  of 
that  resource. 

Automation  of  processes  and  procedures  codifies  the  business  rules  into  the  information 
infrastructure.  When  policies  change,  in  response  to  changes  in  the  environment,  the  rules 
change  accordingly.  The  application  programs  that  implement  those  rules  have  to  be  modified. 
Processes  and  procedures  will  have  to  be  automated  -•  after  all,  that  is  what  automation 
support  is  about  --  but  the  processes  should  not  drive  the  design  of  information  systems. 

Another  reason  for  the  data  emphasis  at  NSWCDD  is  the  use  of  mandated  systems.  Having 
systems  mandated  for  use  by  DoD  or  DoN  or  NAVSEA  in  effect  makes  the  process  and  function  side 
of  the  information  systems  more  volatile.  By  creating  a  corporate  database  environment,  the 
data  required  for  NSWCDD  is  available  regardless  of  who  or  what  processes  the  data;  i.e.,  the 
data  Is  independent  of  either  the  focal  or  mandated  applicatfon.  This  statement  represents  a 
paradigm  shift  from  an  applications  environment  to  a  data  environment.  This  shift  is  a  major 
change  in  the  way  applications  are  developed  and  linked  together.  Interfaces  are  developed 
between  the  systems,  mandated  or  local,  and  the  stable  corporate  database.  All  NSWCDD 
systems  will  be  developed  using  the  corporate  database  and  need  not  be  affected  by  changes  to 
mandated  systems  or  introduction  of  new  mandated  systems. 


1.1  Information  Engineering  Overview 

IE  is  a  data  (k^iven  methodology.  Frequently  represented  as  a  pyramid,  IE  consists  of  four 
major  stages:  Planning,  Analysis,  Design,  and  Construction. 

The  initial  stage,  ISP,  has  three  main  objectives: 

a  an  understanding  of  the  information  requirements  of  the  enterprise 

b.  a  view  of  the  systems  necessary  to  provide  the  needed  information 

c.  a  view  of  the  t^nologies  that  may  be  utilized  to  implement  the  needed  systems. 
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These  objectives  become  manifest  in  the  three  principal  products  of  ISP:  the 
information  Architecture,  the  Buelnese  Systems  Architecture,  and  the  Technical 
Architecture. 

The  Information  Architecture  consists  of  a  data  model  and  a  function  model  that  represent 
the  categories  of  data  that  are  important  to  the  enterprise  and  the  high-level  functions  tiiat  use 


Figure  1-2.  The  Information  Engineering  Methodology 


those  data.  Analyzing  the  interactions;  i.e.,  create,  read,  update  and  delete,  that  exist  between 
functions  and  data  yields  a  Business  Systems  Architecture.  The  Business  Systems  Architecture 
is  comprised  of  logical  data  stores  and  business  systems.  At  the  planning  stage,  the  Technicsd 
Architecture  consists  of  a  model  of  the  types  of  hardware,  software,  and  communications 
technology  that  will  be  required  to  support  the  systems  architecture. 

IE  also  serves  as  an  important  mechanism  for  re-engineering  the  business  itself  by 
virtue  of  the  architectures  it  produces.  The  architectures  constitute  a  model  of  the  business. 
They  can  be  used  fo  suggest  and  evaluate  a  wide  range  of  possible  change,  including 
organizationai  structure  change,  process  irnproveirtem,  and  change  of  business  rules. 
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1.2  NSWCDO  Information  Stratogy  Planning  Project 
1.2.1  Project  Scope 

ISP  is  most  effective  when  the  whoie  enterprise  is  included  in  the  analysis.  The 
NSWCDD  ISP  project  included  NSWCOO  in  its  entirety  and  did  not  limit  its  anstiysis  to  business 
functions  of  the  support  organizations,  but  also  included  functions  that  relate  to  the  "business’ 
of  accomplishing  the  technical  mission  of  NSWCDD. 


1.2.2  Project  Staffing 

Three  teams  participated  in  the  ISP  project.  A  Reference  Team  was  responsible  for 
identifying  high  level  functional  and  information  requirements  of  NSWCDD.  A  Core  Team  was 
responsfole  for  facilitating  requirements  definition  workshops,  modeling  and  analyzing 
Reference  Team  inputs  using  CASE  (Computer  Mded  Software  Engineering)  technology,  and 
synthesizing  the  three  architectures.  An  Advisory  Team  was  also  utilized  in  a  quality  assurance 
role.  The  Reference  Team  consists  of  14  senior  personnel  who  possess  broad  functional 
expertise  of  Center  operations.  The  Core  Team  came  from  the  Systems  Division  personnel.  The 
Advisory  Team  consisted  of  CASE  tool  consultants  from  KnowtedgeWare.  Inc.,  and  IE  consultants 
from  James  Martin  Associates  and  from  the  Fleet  Material  Support  Offk»  (FMSO), 
Mechanicsburg,  Pennsylvania.  Figure  1-3  gives  the  team  staffing  details. 


1.2.3  Approach 

Modeling  is  universally  accepted  by  scientists  and  engineers  as  an  analysis  technique  to 
understand  systems  as  they  are  and  as  they  ought  to  be.t  Modeling  is  fundamental  to  the  IE 
methodology  and  provides  the  engineering  rigor  necessary  to  design  sophisticated,  integrated 
information  systems.  The  overall  objective  of  the  ISP  project  was  to  develop  a  model  of 
NSWCDD  in  terms  of  the  activities  it  performs  and  the  information  it  holds  important. 

The  Reference  Team,  as  experts  on  the  business  of  NSWCDD,  provided  three  primary 
inputs  to  the  modeling  process: 

a  major  functions  performed  by  NSWCDD 

b.  me^r  categories  of  information  of  interest  to  NSWCDD 

c.  rules  that  govern  how  business  is  conducted  at  NSWCDD 

Thfo  information  was  identified  within  the  forum  of  short  (2  or  3  day)  workshops  facilitated  by 
the  Core  Team.  During  the  workshops,  the  Reference  Team  constructed  data  models  and  function 
models .  Between  workshops,  the  Core  Team  analyzed  the  models  in  detail,  modffied  them  where 
necessary  to  ensure  consistency  in  level  of  detail,  and  documented  the  results  for  review  by  the 
Reference  and  Advisory  Tewns. 
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Participants 

Team  Roles 

Core  Team 

Rod  Burrell,  E51 

Tina  Reese,  ESI 

Ken  Trusiow.  E54 

Melba  Hye-Knudsen,  E51 

o  CASE  Tool  modeling 
o  detailed  analysis 
o  product  preparation  and 
distribution 

0  workshop  facilitation 

Reference 

Team 

FCCM  Dan  Reedal.  C4 

Chuck  Berkey,  02 

Bud  Wiseman,  E 

Ray  Pollock,  E 

Willard  Innis,  G 

Linda  Loeffter,  K 

Harvey  Williams,  M 

Bev  Goldman,  M 

Larry  Dabbs,  M 

Bill  Ferreira,  P 

Ken  Caudle,  R 

Carl  Larsen,  R 

Judy  Schmidt,  S 

BobOtte,  U 

Ed  Reiso,  W 

o  data  and  function  model 
development 

o  identification  of  business 
rules 

o  product  validation 

Advisory 

Team 

Fleet  Material  Support  Office 
James  Martin  Associates 
Knowledgeware,  Inc. 

Carol  Wilson,  E50 

Carol  Burleson,  E54 

0  methodology  consultation 
o  CASE  tool  consultation 

0  quality  control 

Figure  1*3.  ISP  Team  Memberehip 


1.2.4  CASE  Tool 

Release  5.01  of  the  Information  Engineering  Workbench  (lEW),  a  product  of 
KnowledgeWare,  Inc.,  was  used  to  support  the  ISP  project.  The  platform  was  a  25  MHz  80386- 
based  personal  computer,  with  8  Mbytes  of  RAM,  and  running  DOS  3.3. 
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CHAPTER  2 

BUSINESS  STRATEGY 


The  foundatton  for  the  ISP  is  the  business  strategy  plan  for  NSWCDD.  A  thorough 
understanding  of  NSWCDD's  business  strategy  planning  is  essential  to  determine  the  future 
information  needs  of  NSWCOO  and  to  establish  a  consistent  Information  Strategy  Plan  that  will 
support  the  future  business  requirements.  In  order  to  set  priorities  for  foe  work  identified  by 
the  analysis  of  information  and  functions  required  by  NSWCDD  in  the  performance  of  its 
business,  we  need  to: 

a  determine  the  business  priorities  from  which  the  information  priorities  will  be 
derived 

b.  identify  the  possible  future  developments  of  NSWCDD  or  external  events,  which 
should  influence  the  direction  of  foe  automation  efforts  in  the  NICCS  program  as 
it  supports  the  needs  of  NSWCDD 

c.  make  foe  Board  of  Directors  (BOD),  and  NSWCDD  managers  in  general,  aware  of 
the  possible  impact  of  information  technology  on  the  way  NSWCDD  conducts  its 
business 

In  the  sections  below  each  of  these  items  are  discussed. 


2.1  Analyaie  of  the  Business 

The  current  mission  of  NSWCDD  is: 

Provide  research,  development,  test  and  evaluation,  engineering  and  fleet 
support  for  surfoce  warfore  systems,  surface  ship  combat  systems,  ordnance, 
mines,  amphfoious  warfare  systems,  mine  countermeasures,  special  warfare 
systems,  and  strategic  systems.  Execute  other  responsibilities  as  assigned  by  the 
Commander,  Naval  Surface  Warfare  Center. 

The  following  guiding  principles  are  from  an  internal  draft  of  12/18/91  on  the  mission, 
guiding  princfoles,  and  vision  for  NSWCDD. 

a  We  exist  to  provide  our  customers  with  quality  products  and  services,  cmd  to 
provide  the  Navy  with  a  soimd  technicai  basis  to  obtain  material  resources 
required  by  foe  Fleet  and  foe  Marine  Corps, 
b.  We  will  balanoe  the  two  prfncipie  means  to  achieve  this  end: 

-  be  responsve  to  our  customer's  cwrent  needs  to  carry  out  assigned  tasks 

-  anticipate  and  prepare  to  support  the  Navy's  future  needs 
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c.  We  will  be  characterized  internally  by  a  culture  which  holds  all  employees  as  the 
foundation  of  our  excellence. 

Figure  2-1  lists  the  NSWCOO  business  goals  based  on  this  mission  and  gukUng  principles.  Also 
included  are  the  IRM  goals  set  forth  in  the  Master  Plan2  document  for  the  NICCS  program. 


NSWCDD  BUSINESS  GOALS 


1.  Hrolhe  best  people,  assign  chalenging  work  provide  Item  state  of  Ihe  art  equipi^ 
ard  create  an  environment  lhat  erebies  twm  to  develop  themselves  aid  keep  iBCtinol^^ 


2.  Be  valued  by  our  customers.  Be  roootpiaed  as  a  spolrosman  for  tedinkal  truth,  ard  a  (analyst  to  promote 
the  surface  ard  strategic  warfaro  oornmunilies' krwwledge  ard  use  ol  technotogy. 

3.  Conttoue  overall  gro«vto  in  tsrhrwtogy  based  work,  wito  increased  emphasis  on  fundamental 
rraihernatical  and  plysical  principles,  and  on  our  abity  to  conceive  and  bidd  proto^pes. 

4.  Estabishqually  and  process  improvernent  as  tie  cornerstones  of  provdtog  our  products  and  services, 
and  in  our  business  practices. 


NSWCDD  IRy  GOALS 


a.  Plan  ardhifolernertvald  cost-effective  inforinaiionsystsnsttiataro  based  on  defined 
informaiion  requiretnerfo  ard  tw  aro  designed  to  MIy  exptoit  current  ard  emergirg  information 
technology  to  support  ard  enhance  NAVSWC  nussion  peilorma^ 


b.  Enhance  cornrnardproductiviiytirouj^appicaion  of  labor- and  cost-saving  prograrns  to  offset 
resource  deficiencies. 


c.  totsgrate,slrearrtir»,ardsirnpiiyinforinalion  resource  wdinibrmalion  system 
to  proviite  needed  inforinaion  resources  in  t»  niost  useful,  tknely,  ard  econornfo  nianner. 


d.  Protect  inforniaiion  tom  accdentaLunautiorind,  or  intenionaldastrucfon,rrKdil^^ 
dfocioeuro,  or  denial  of  servios. 


Figur*  2>1.  NSWCDD  BuefnM*  and  IRM  Goals 
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Figure  2-2  contrasts  the  business  goals  of  NSWCDD  with  those  of  NAVSEA  laid  out  in  their 
Information  Resource  Strategy  Plan .3 
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Figure  2-2.  NSWCDD  va  NAVSEA  Business  Goais 


The  current  NSWCDD  vision  documenH  identified  several  strategic  needs  that  relate  to 
informatton  management.  These  needs  point  to  the  diversity  of  information  use  at  NSWCDD  and 
to  its  irT^x>rtance  to  the  success  of  NSWCDD. 

a  The  individuai  technical  efforts  be  integrated  across  Departments  and 

crganizationai  units  whenever  those  efforts  have  an  imp^  on  one  another.  We 
must  build  effective  Information  links  throughout  the  Center  to  keep 
managers,  supervisors,  and  working  level  groups  informed  of  one  another's 
progress  and  use  this  information  to  strengthen  the  interoperability  of  the 
products  that  will  ultimately  be  delivered  to  the  Fleet. 

b.  The  employment  of  efficient  business  practices  to  manage  the  public 
resources  entrusted  to  us. 
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c.  The  Center  is  not  simply  the  aggregate  of  a  number  of  Departments  acting 
independently  of  one  another;  rather,  it  is  a  collective  whole,  with  ail  of  the 
sharing  many  common  interests,  responsibilities,  and  problems. 

d.  The  Center's  business  processes  must  take  maximum  advantage  of 
automation,  and  the  management  information  requirements  of  Center  managers 
at  all  levels  need  to  be  met  more  effectively  and  efficiently. 

e.  The  initiation  of  a  concerted  effort  to  meet  Center  managers'  information  needs, 
including  implementation  of  appropriate  organizational  change  required  to 
meet  these  needs. 

NSWCDO  has  not  spedficaliy  defined  any  critical  success  factors,  although  the  goals 
define  what  NSWCOD  considers  to  be  important  in  the  pursuit  of  its  business.  Inhibitors 
include  a  scarcity  of  scientists  and  engineers  forecast  in  the  year  2000  coupled  with  the 
current  salary  structures  within  the  Federal  sector.  The  drav^wn  in  DoD  does  not  contribute 
to  our  ability  to  hire  and  retain  the  best  people.  NSWCDD  has  traditionally  been  conscious  of 
providing  technically  current  equipment.  The  information  technology  support  in  all  areas  of 
NSWCDD  is  quite  good.  Shrinking  capital  funds  is  an  inhibitor  to  acquiring  the  needed 
information  technology  for  the  business  support  areas.  The  information  resource  initiatives  in 
our  parent  organizations  could  be  a  help  or  an  inhibitor,  depending  on  the  timing  of  mandated 
systems  and  the  manner  of  implementation.  The  introduction  of  Total  Quality  Leadership 
initiatives  within  NSWCDD  is  a  positive  step  in  revamping  the  business  processes.  It  affords  an 
opportunity  to  automate  improved  processes,  which  is  needed  if  the  investment  in  automation  is 
to  be  cost-effective.  Automation  of  processes  designed  to  be  somewhat  effective  manually, 
without  redesign  to  take  advantage  of  automation,  normally  increases  the  life-cycle  cost  of  the 
process  -  not  improves  it.  On  the  downside,  a  surge  of  activity  in  this  area  can  quickly  and 
easily  swamp  the  available  resources  for  automation  support.  There  may  well  be  a  need  to 
cross  traditional  organizational  boundaries  to  effect  the  best  return.  A  very  real  inhibitor  is 
the  extreme  vertical  nature  of  DoD  and  its  components.  The  preliminary  work  from  CIM  does 
not  seem  to  go  away  from  this  perspective.  When  functionality  is  emphasized,  the  result  often 
looks  like  the  current  environment.  NSWCDD  chose  the  data  emphasis  because  its  seems  less 
sensitive  to  current  vertical  processes. 


2.2  Drivers  and  their  Impact 

2.2.1  DoD  Budget  Cute  and  Workforce  Reductions 

The  DoD  budget  cuts  and  work  level  restrictions  will  cause  changes  in  the  way  NSWCDD 
does  its  business.  Cuts  to  the  budgets  of  our  sponsors  will  surely  be  felt  in  the  funding  profile. 
Reductions  in  direct  money  will  require  reductions  in  the  overhead  costs.  One  of  the  greatest 
challenges  we  face  will  be  sustaining  our  tAllity  to  meet  our  responsibilities  with  fewer  people 
The  improvement  of  business  practices,  whether  by  automation  or  not,  must  reckice 
substantifirily  the  numbers  of  people  or  the  amount  of  personnel  time  involved  in  the  business 
practices  so  that  the  generation  of  the  NSWCDD  products  is  less  severely  impacted. 
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2.2.2  DoD  Corporate  Information  Management  (CIM)  Program 

The  CIM  Program  for  the  OoD  is  a  very  challenging  and  aggressive  IRM  initiative.  CIM 
focuses  on  the  improvement  of  business  practices  through  consolidations  and  standardization.  It 
will  be  operated  in  a  centralized  IRM  policy  and  practices  but  decentralized  execution  mode.  The 
Computer-aided  Acquisition  Logistic  Support  (CALS)  Program  has  been  placed  under  the  CIM 
umbrella.  CIM  is  aggressively  pursuing  other  standards  via  increased  funding  to  the  National 
Institute  for  Standards  and  Technology  (NIST).  The  Electronic  Data  Interchange  (EDI)  Program 
is  also  under  CIM.  The  CIM  approach  will  bring  about  massive  changes  in  the  way  business  is 
conducted  in  the  DoD  by  enabling  large-scale  business  process  improvements.  Their  approach 
is  similar  to  the  approach  being  used  by  the  NICCS  Program.  Both  are  using  IE  as  foe  basic 
systems  engineering  approach.  NSWCDD  emphasizes  data  over  function  and  CIM  emphasizes 
function  over  data.  CIM  should  provide  NSWCDD  with  standardized  automated  programs  and 
processes.  The  use  of  standard  systems  should  lower  our  development  and  maintenance  costs. 
The  ISP  and  foe  following  work  on  Business  Area  Analysis  (BAA)  will  prepare  NSWCDD  for  the 
incorporation  of  standard  systems  into  its  architectures. 


2.2.3  Navy  and  NAVSEA  IRM  Initiatives 

Both  the  Department  of  the  Navy  and  NAVSEA  are  involved  in  IRM  initiatives.  In  both 
cases  those  initiatives  are  endeavoring  to  remain  consonant  with  the  direction  of  CIM  and 
NAVSEA  with  the  DoN  efforts.  NSWCDD  must  endeavor  to  likewise  satisfy  the  demands  placed  on 
it  by  these  programs.  DoN  and  NAVSEA  both  emphasize  functionality  over  data,  which  is  not  foe 
approach  being  taken  by  NSWCDD. 

The  Navy  IR  Strategic  Plan^  of  April  1991  defines  issues  and  objectives  and  gives  the 
following  emphases: 

a  Management  of  information  as  a  strategic  resource 

b.  Realization  of  the  Dod  CIM  initiatives  wherein  information  is  shared  through  an 
open  systems  architecture,  systems  are  standardized,  and  resources  are 
consolidated  across  and  among  the  senrices. 

c.  Streamlined  planning,  programming,  budgeting,  executing  and  appraisal 
processes,  life-cycle  management  processes,  and  acquisition  processes  that 
enable  rapid  achievement  of  mission  objectives. 

d.  A  data,  computer,  and  communication  structure  that  is  acquired  through  full  and 
open  competition  with  heterogeneous  technology  transparent  to  its  users  and 
developers. 

a  A  military  and  civilian  workforce  that  is  highly  competent  and  responsive  to  DoN- 
mission  requirements. 
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NAVSEA  states  that  its  IRM  goals  are  oor)»stent  with  these  DoN  emphases.  The  NICCS  Program 
has  been  moving  in  the  direction  of  CIM  and  DoN  emphases  for  NSWCDD  since  1989.  These 
initiatives  of  parent  organizations  will  not  cause  any  philosophical  changes  to  the  NICCS 
Program.  The  particular  manner  of  fulfilling  these  objectives  will  vary  from  organization  to 
organization.  In  the  implementation  arena,  the  NICCS  program  varies  with  both  CIM  and 
NAVSEA.  The  Business  Areas  developed  by  each  organization  reflects  the  particular  needs  of  that 
organization  to  perform  its  mission.  Each  organization  has  similar  goals  but  as  we  traverse 
down  the  change  of  command,  each  organization  has  a  particular  mission  and  the  information 
systems  needed  to  help  it  satisfy  its  particular  goals  will  be  implemented  differently.  The 
issues  of  effectiveness  and  efficiency  come  forward  in  the  actual  definition  of  Business  Areas  and 
their  related  information  system  strategies.  The  key  is  to  have  the  IRM  goals  line  up  both  with 
the  business  needs  of  the  organization  and  with  the  IRM  strategies  of  the  parent  organization. 
Figure  2-3  shows  the  relationship  between  the  business  goals  of  NSWCDD  and  its  IRM  goals. 
Figure  2-4  shows  the  relationship  between  the  IRM  goals  of  NSWCDD  and  the  IRM  strategies  of 
NAVSEA.  There  is  good  correlation  and  support  in  both  areas. 
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Figure  2*3.  NSWCOO  IRM  vt  Bueinees  Goal* 
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Figure  2-4.  NSWCDD  ve  NAVSEA  IRM  Goale 


2.2.4  Navy  RDTAE  Center  Conaolidatlon 

The  consolidation  of  the  RDT&E  Centers  within  the  DoN  will  change  the  physical 
characteristics  of  NSWCDD.  The  shift  in  the  locations  of  personnel  and  the  addition  of  other 
physically  distant  sites  will  affect  the  communications  bac^ne  of  NSWCDD.  The  addition  of 
another  m«yor  detachment  and  the  reduction  of  a  current  detachment  place  even  a  larger  burden 
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on  the  information  sharing  aspects  of  the  NICCS  program.  The  need  for  automation  support  in 
collaboration  of  research  efforts  and  the  production  of  non-hardware  products  and  services  is 
critical  to  the  proper  and  effective  use  of  personnel.  The  availability  of  business  information 
and  support  at  remote  sites  is  accented. 


2.2.5  Total  Quality  Management 

NSWCDD  is  in  the  process  of  establishing  a  TQM  environment.  This  change  in 
organizational  and  mangerial  philosophy  will  have  a  mayor  impact  on  the  design  and 
implementation  of  information  systems.  Every  other  business  change  that  has  occurred  in  the 
past  has  been  designed  to  move  complexity  out  of  the  work  environment  and  to  move  information 
handling  up  the  organization  ladder.  Now,  we  are  giving  decision  making  responsibility  to  the 
lowest  possible  level.  To  be  able  to  make  decisions,  tfie  employees  of  NSWCDD  will  need 
information.  Three  things  will  affect  the  information  processing  scenario.  First,  the  type  of 
information  will  change  at  different  levels  from  what  it  has  been  in  the  past.  In  particular,  for 
TQM  to  work,  each  employee  needs  to  know  the  vision,  direction,  and  evaluation  criteria  that 
combine  to  tell  him  or  her  what  constitutes  success  for  the  organization.  Without  this 
information,  the  employee  cannot  consistently  make  proper  decisions;  i.e.,  decisions  that  will 
move  the  organization  on  towards  improved  productivity  and  client  satisfaction.  Traditionally 
such  information  has  been  given  selectively  to  managers  at  different  levels.  Now  the  field  is 
wide  open.  Second,  the  field  is  wide  open  and  since  decisions  will  be  being  made  by  more  people, 
the  sources  of  information  will  be  much  more  widely  dispersed.  At  NSWCDD  there  is  great 
physical  distance  between  major  locations  and  physical  distances  betw  oen  people  who  need  to 
share  information  at  a  particular  site.  The  availability  requiremeiits  and  timeliness 
requirements  still  remain,  and  need  to  satisfy  many  more  people.  This  need  should  affect 
technical  design  decisions;  i.e.,  move  away  from  large  central  databases  because  of  potential 
reliability  and  performance  problems.  Third,  TQM  and  IE  have  a  great  overlap  in  purpose  and 
process.5  NSWCDD  will  need  to  mesh  its  efforts  in  these  two  areas. 


2.3  Impact  of  Information  Technology 

Information  technoiogy  (IT)  has  and  wilt  continue  to  have  a  large  impact  on  the  way 
NSWCDD  conducts  it  business  and  operates  its  business  processes.  The  use  of  computing  in 
support  of  the  delivery  of  its  products  goes  back  over  40  years  to  the  very  early  use  of 
computers.  The  use  of  computers  to  process  its  business  information  dates  back  over  30  years. 
The  introduction  of  the  enterprise-wide  office  automation  system  10  years  ago  set  the  stage  for 
even  greater  acceptance  of  IT  in  most  areas  of  work  with  the  introduction  of  personal  computers 
and  workstations  across  the  board.  Despite  the  heavy  automation  within  NSWCDD  today  many 
opportunities  still  exist  for  improvements  based  on  judicious  use  of  automation  support. 

At  any  enterprise,  end  user  or  client  IT  activities  will  vary  in  how  sophisticated  is  their 
use  of  IT.  The  levels  of  sophistication  and  types  of  use  constitute  a  maturity  spectrum.  Both 
clients  and  their  applications  can  become  more  sophisticated  if  handled  properly,  or  sometimes 
merely  through  the  passage  of  time.  The  application  maturity  stage  for  the  enterprise  is  taken 
to  be  the  stage  where  the  greatest  proportion  of  client  application  development  resources  are 
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being  expended.  Figure  2-5  shows  maturity  stages  of  end-user  computing.^  It  is  possibie  to 
navigate  NSWCDD  through  the  stages.  Currently  NSWCDD  is  transitioning  from  Stage  2:  Stand¬ 
alone  to  Stage  3;  Manual  Integration.  This  transition  is  marked  by  the  emergence  of  significant 
volume  of  electronic,  though  manually  controlled,  data  interchange.  The  next  transition  to 
Stage  4:  Automated  Integration  will  be  marked  by  the  development  of  automated  data  transfer 
systems  and  the  devebpment  and  use  of  the  DA  function.  The  NICCS  Program  is  moving  in  this 
direction.  The  DA  function  is  underway  and  is  coordinating  its  activities  with  the  DA  activities 
of  DoN  and  CIM.  Some  preliminary  work  has  occurred  to  work  out  automated  data  exchange 
techniques,  although  it  still  has  a  long  way  to  go.  The  long-range  plans  for  NICCS,  as  discussed 
in  Chapter  5,  would  move  NSWCDD  into  Stage  5:  Distributed  Integration.  The  transition  will 
involve  moving  to  a  distributed  database  environment.  The  technology  is  not  available  for 
production  status.  The  NICCS  Program  has  instituted  a  simulation  laboratory  to  explore  various 
alternatives  for  the  technical  architectures.  One  of  the  investigations  undenway  involves 
distributed  data  processing  in  our  environment. 


2.3.1  [G]  IT  as  a  Product  or  Part  of  a  Product 

NSWCDD  is  already  aware  of  the  uses  of  IT  as  a  product  itself  or  as  part  of  a  product  it 
develops.  Quite  a  few  of  the  products  that  are  developed  at  NSWCDD  are  IT  products.  NSWCDD  is 
heavily  involved  in  the  software  business  as  it  relates  to  support  of  its  mission  areas.  NSWCDD 
uses  CAD/CAM  and  visualization  graphics  in  its  hardware  business.  Within  the  industry, 
automation  efforts  to  support  feasibility  and  design  is  moving  into  new  areas;  e.g.,  virtual 
reality  environments  are  a  big  leap  from  conventional  training  simulators  and  test  networks. 
The  use  of  information  technologies  of  the  future  are  being  explored  now  at  NSWCDD. 


2.3.2  [Y]  IT  as  a  Medium  for  Delivering  Products 

This  area  will  continue  to  evolve  in  response  to  the  DoD  CALS  Program.  The  NSWCDD 
CALS  Program  is  working  with  NICCS  and  has  some  programs  experimenting  with  the  CALS 
standards  as  they  come  out.  The  use  of  hypermedia  techniques  and  technologies  could  change  the 
way  NSWCDD  delivers  its  products.  Some  programs  are  now  trying  hypermedia  techniques  in 
the  training  and  maintenance  areas. 


2 . 3 . 3  [  R  ]  IT  as  a  Marketing  Instrument 

NSWCDD  does  not  use  automation  in  support  of  this  function.  With  the  reorganization  of 
the  RDT&E  community,  it  might  appear  on  the  surface  that  this  is  no  longer  an  important 
function.  The  centers  are  no  longer  to  compete  with  each  other  but  have  their  areas  of  expertise 
defined.  NSWCDD  works  in  many  leading-edge  automation  technologies;  e.g.,  neural  networks. 
The  fact  remains  that  the  centers  must  compete  with  the  private  sector  for  work  and 
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Stage  1:  ISOLATION 

o  little  or  no  exchange  of  data  or  programs  with  other  applications 
o  applications  more  for  understanding  than  to  perform  substantiai  work-related  tasks 
o  laissez-faire  management;  i.e.,  no  attempt  to  support  end  user  computing 
o  largely  no  enterprise-wide  planning  and  control  for  erfo  user  computing 
o  largely  no  erfo  user  computing  support  or  training 


Stage  2:  STAND-ALONE 

o  end  user  dependence  on  applications  is  observable 
o  applications  restricted  to  client  or  his/her  work  group 
o  data  passed  by  manual  methods 

o  begin  to  establish  procedures  for  the  evaluation  artd  acquisition  of  new  end  user 
hardware  and  software 

o  initial  operating  policies  artd  procedures  introduced  for  backup,  recovery, 
security 

o  end  user  support  group  assists  in  hardware  arfo  software  evaluations 


Stage  3:  MANUAL  INTEGRATION 

o  clients  exchange  substantial  amounts  of  data  and/or  programs  with  each  other 
o  data  transfer  is  not  integrated  within  the  application  but  occurs  manually  external 
to  the  application 

o  need  some  startdardization  between  applications  exchanging  data  leading  to  data 
administration  furtction 

o  requirement  for  cost-benefit  analysis  for  client  systems 
o  emergence  of  appiication  development  discipline 


Stage  4:  AUTOMATED  INTEGRATION 

o  advent  of  true  integrated  systems 

o  clients  and  developers  must  possess  information  on  where  data  exists  and  how  to 

best  get  to  it  for  new  application  development 

o  linking  of  client  community  with  the  central  systems  group 

o  competent  arrd  eftactivo  management  of  data  at  all  levels  of  computing  power 

becomes  critical  to  the  business  functioning  of  the  enterprise 

o  clients  are  required  to  adopt  an  application  development  disciplirte 

o  less  client  freedom  because  of  ne^  for  interoperability 


Stage  5:  DISTRIBUTED  INTEGRATION 

o  shared  databases  exist  at  desktop,  organization  and  enterprise  levels 
o  standardized  software 

o  use  of  distributed  database  systems,  multi-level  dictionaries,  arfo  other 
network/system  tools  [not  currently  avmllable] 

o  increasing  number  of  senior  managers  use  microcomputars  because  information 
from  all  aspects  of  the  business  is  more  readily  aocessIM 
o  teams  developing  sophisticated  cross-functional  applications 


Figure  2-5.  Stages  of  End-Ueer  Computing 
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will  still  compete  for  block  money.  In  an  intensely  competitive  arena,  marketing  becomes  very 
important.  With  DoD  budgets  being  cut  substantially,  there  will  be  intense  competition  for 
scarce  funds.  NSWCDD  could  apply  automation  support  in  this  area,  much  like  the  private 
sector  in  the  gathering  of  our  own  ty^  of  marketing  data.  NSWCDD  does  strategic  (inning  from 
the  top-down  and  should  be  using  marketing  forecasting  to  project  what  areas  and  sponsors  K 
should  be  working.  NSWCDD  does  not  have  a  well-defined  marketing  approach  at  this  time, 
which  makes  automation  support  in  this  area  difficult.  This  area  has  potential  for  pay-off  in 
the  future  environment  of  more  competition  for  less  resources. 


2.3.4[R]  IT  as  a  Competitive  Tool  of  Management 

One  of  the  main  drivers  for  the  NICCS  Program  was  the  awareness  at  NSWCDD  that  its 
information  systems,  particuiarly  its  business  systems,  were  not  supporting  the  needs  of 
management.  NSWCDD  needs  integrated  information  in  its  decision-making  as  it  positions  itself 
in  the  near  and  the  long  terms.  Isolated  pockets  of  information  technology  support  have 
occurred,  but  the  integration  is  not  there.  Information  technology  is  being  applied  in  the 
personnel  area  the  most  effectively.  The  financial  systems  are  terrible  as  is  to  be  expected 
when  an  almost  20  year  moratorium  on  their  upgrade  was  endured.  Obtaining  of  financial  goals 
is  difficult  because  the  proper  information  is  not  available  throughout  the  year  to  make 
adjustments  to  strategies  and  plans.  Lack  of  good  IT  support  places  a  drain  on  productive  time 
throughout  the  organization  as  fire  drills  and  information  gathering  is  performed  manually  and 
there  is  no  ability  to  use  previously  gathered  data  in  a  new  slant.  This  ISP  and  the  ensuing  woik 
has  as  their  goals  the  solution  to  these  problems  of  good,  reliable,  timely,  and  integrated 
management  information. 


2.4  Strategic  laauea  and  Priorities 

NSWCDD  has  an  operational  need  to  p^orm  its  business  functions  using  fewer 
resources  than  its  current  baseline,  by  at  least  25  percent  in  the  personnel  resource.  This  need 
is  driven,  not  by  possible  drawdowns,  but  because  the  overhead  expenditures  need  to  be 
lowered.  The  reduction  in  direct  dollars  to  NSWCDD  is  a  real  threat  and  would  need  fewer 
overhead  dollars  to  be  expended  to  keep  the  rates  the  same.  This  reduction  must  not  lengthen  the 
mean-time-to-complete  any  basic  business  function  and  maintain,  and  perhaps  enhance,  the 
integrity  and  repeatability  of  the  NSWCDD  decision-making.  This  need  is  borne  out  of  the 
external  environment  of  DoD  budget  cuts,  drawdowns  and  to  help  NSWCDD  lower  ifo  rates  by 
lowering  its  overhead  expenditures.  This  need  is  probably  the  primary  driver  for  the  NICCS 
program. 

The  second  need  relates  to  the  real  busfoess  of  NSWCDD.  NSWCDD  has  a  need  for  better 
information  flow  within  the  bounds  of  its  organization  and  with  outside  sources.  The 
information,  which  needs  to  flow,  is  both  technical  and  business.  NSWCDD  is  in  the  knowledge 
business  since  it  is  an  R&D  center.  The  need  for  Information  flow  for  collaboration  is  high  and 
the  need  fo  easily  and  effectively  access  information  sources  outside  of  NSWCDD  would  be  a 
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pnxkjctive  boost  to  the  technical  staff.  Managers  need  better  business  information  in  a  more 
timely  fashion  and  in  a  better  presentation  style. 

The  final  need  is  a  more  effective  use  of  IT  in  the  support  of  managers.  NSWCDD  uses 
information  technology  in  the  generation  of  its  products,  but  needs  to  better  utilize  the 
capabilities  of  automation  support  in  the  other  areas.  The  need  to  perform  its  business 
functions  more  effectively  and  the  lack  of  automation  in  marketing  and  general  decision-making, 
both  at  an  enterprise  level  and  an  organizationai  unit;  e.g.,  branch,  program,  office,  requires 
NSWCDD  to  move  through  the  stages  of  end-user  computing  as  described  above. 

The  two  key  dimensions  of  moving  through  the  stages  are  (1)  the  rate  of  expansion  of 
client  application  development  and  (2)  the  direction  of  its  development;  i.e.,  how  applications 
are  developed.  The  expansion  (fimension  may  be  affected  by  manipulating  such  things  as  the  flow 
of  information  to  the  client  community,  costs  borne  by  the  clients,  the  availability  of 
capitalization  funds  to  acquire  new  technology,  and  the  support  and  assistance  provided  to  the 
client  community.  The  direction  that  development  takes  can  be  controlled  by  restrictions  placed 
on  hardware  and  software  selections,  platform  usage  policies,  and  the  nature  of  access  to  the 
NSWCDD  corporate  database(s).  Figure  2-6  shows  four  development  strategies  depending  on 
the  level  of  expansion  permitted  and  the  level  of  control  exerted  by  the  central  systems  group. 

Many  external  and  internal  drivers  to  the  NICCS  Program  would  affect  how  we  try  to 
manage  in  this  grid.  Flexibility  is  the  key  in  the  current  business  environment  of  NSWCDD. 
Some  examples  of  different  strategies  follow.  Tight  IT  budgets  but  loose  budgets  in  the  client 
areas  might  lead  to  acceleration  or  controlled  growth,  depending  on  how  good  we  are  in  the 
standards  and  policies  arena  at  that  point  in  time.  Lack  of  expertise  in  the  business  client  areas 
might  suggest  containment  as  a  strategy,  while  we  work  on  bringing  their  skill  levels  up  to  a 
level  that  we  feel  comfortable  with  them  developing  their  own  systems  under  our  guidelines. 
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Figure  2*6.  Development  Strategy  Grid 
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CHAPTER  3 

INFORMATION  ENVIRONMENT 


3.1  Current  Information  Environment 

Center  management  has  recognized  the  symptoms  that  indicate  problems  with  our 
current  information  environment.  The  white  paper^  produced  by  the  Finance  and  Business 
Systems  Board  highiighted  'our  inability  to  got  accurate  and  appropriate  information  to  the 
right  people  at  the  right  time'.  What  are  the  characteristics  of  our  information  environment 
that  ied  to  this  conclusion? 

Over  the  years,  an  inventory  of  information  has  built  up  in  paper  files,  punched  cards, 
magnetic  tape  and  disks  and.  in  some  cases,  in  people's  heads.  Although  we  have  this  information 
resource,  there  must  be  some  inherent  limitations  associated  with  it  that  cause  the  problems 
cited  above.  Indeed,  the  problems  with  this  inventory  of  information  actually  originate  from  the 
design  approach  that  produced  it.  Until  very  recently,  we  designed  information  systems  to 
functional  specifications;  i.e.  designed  based  on  what  the  system  had  to  do.  Data,  rather  than 
being  the  driving  design  force,  only  supported  the  particular  functional  requirements  of  the 
system.  The  result  Is  data  customized  for  each  and  every  application.  Data  repeated  for  each 
application  that  needed  it.  This  approach  to  systems  design  caused  some  worrisome  problems; 
e.g.,  lots  of  source  code  and  data  files  to  maintain  and  inconsistencies  in  data  definitions.  But, 
the  approach  generally  was  workable  in  the  world  of  stand-alone  systems,  hardcopy  reports, 
and  undemanding  clients. 

Today's  clients  are  more  demanding  of  information  technology;  they  want  systems  that 
give  them  the  information  they  need  when  they  need  it.  They  have  become  more  aware  of  the 
possibilities  afforded  by  information  technology.  They  witness  the  advances  at  the  checkout 
counter,  the  bank,  and  virtually  every  facet  of  their  lives.  Clients  expect  fiexble  systems  that 
can  meet  their  changing  needs  and  meet  them  rapkfly.  To  meet  these  expectations,  the  design 
focus  must  not  be  on  what  the  system  has  to  do,  but  on  what  information  the  system  has  to 
provide.  Thus,  data  must  become  the  force  that  drives  systems  design. 

The  current  NSWCDO  information  environment  is  a  product  of  the  functionally  diiven 
design  approach.  Most  of  our  business  systems  are  written  in  second  generation  COBOL  and  are 
supported  by  flat  data  files.  Some  dcta  are  even  embedded  in  appVcation  programs  or  in  the  job 
control  statements  that  run  them.  Data  definitions  and  formats  are  not  standartfzed,  so  data  are 
more  frequently  replicated  than  shared.  Redundant  data  files  are  commonplace  and  expensive  to 
maintain.  In  short,  our  current  information  environment  cannot  effectively  support  NSWCDD 
in  the  rapidly-changing,  information-intensive,  competitive  business  world  in  which  we  find 
ourselves. 
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3.2  Defining  A  New  information  Environment 

The  information  environment  to  which  NSWCDD  must  transition  will  be  characterized 
by  data  stored  in  relational  databases;  defined  and  standardized  from  the  enterprise  perspective, 
and  independent  of  the  specification  of  any  particular  application.  Applications  will  share  data, 
not  own  it.  Clients  will  be  able  to  access  databases  and  extract  the  data  they  need.  Many 
requirements  for  information  will  be  handled  by  the  databases,  without  arty  programming  at  all. 
This  environment  requires  that  information  be  managed  as  a  resource,  just  like  the  financial, 
human,  and  physical  resources  that  support  NSWCDD's  mission. 


3.3  Information  Architecture 

The  heart  of  the  specification  baseline  for  the  new  information  environment  is  the  set  of 
models  that  comprise  the  Information  Architecture.  Enterprise  analysis  considers  the  data  used 
and  the  activities  performed  by  the  enterprise  and  defines  the  function  and  data  models.  The 
objectives  of  this  analysis  to: 

a  develop  a  view  of  NSWCDD  functions  independent  of  organizational  structure 

b.  identify  the  fundamental  categories  of  data  that  are  important  to  NSWCDD 

c.  devek^  a  view  of  how  data  is  used  to  support  NSWCDD  functions 

In  the  sections  below  ,  we  will  discuss  the  function  and  the  data  models.  These  two  models  make 
up  the  Information  Architecture.  Both  the  models  and  the  processes  used  to  define  them  will  be 
discussed.  Finally,  the  interaction  of  function  and  data  will  be  discussed  and  the  ramifications 
on  NSWCDD. 


3.3.1  Functional  Model 

An  objective  of  ISP  is  to  develop  a  functional  model  of  the  enterprise  that  is  not 
influenced  by  existing  organizational  structure.  Therefore,  emphasis  was  placed  on  'whaf 
NSWCDD  d(^,  and  not  on  'Vrho’  does  it.  A  functionai  decomposition  diagram  describes  the 
function  model.  Although  these  diagrams  look  much  li^e  organizational  charts,  we  must 
remember  that  the  function  model  defined  by  the  ISP  prefect  is  independent  of  organizational 
structure.  This  purely  functional  view  allows  opportunities  for  process  improvement  and  data 
sharing  from  a  neutral,  non-parochial  point  of  view. 

NSWCDD  accomplishes  its  mission  by  responding  to  the  needs  of  the  surface  Navy. 

These  needs  are  sometimes  expressed  to  NSWCDD  through  sponsor  organizations  and  somethnes 
are  identified  through  the  RAD  activities  of  NSWCDD  itself.  A  top-level  view  of  NSWCDD 
reveals  three  major  functional  areas  as  shown  in  Figure  3-1.  The  Product  and  Servioa 
Davek^ment  functional  area  determines  the  requirements  for  responding  to  those  needs  and 
communicates  the  requirements  to  the  Organization  Management  area.  Organizadon  Management 
then  authorizes  allocations  of  resources  to  be  provided  by  the  Resource  Management  functional 
area. 
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Although  this  representation  of  NSWCOO  is  extremely  simplified,  it  does  provide  a 
structure  for  thinking  about  the  major  functions  necessary  for  NSWCDD  to  do  its  business. 

From  this  conceptualization,  the  ISP  Functional  Model  was  developed.  The  Resource  Management 
functional  area  divides  further  into  the  six  resource  specific  areas.  Figure  3-2  shows  the  top- 
level  ISP  Function  Model. 

The  functional  decomposition  is  verified  by  a  technique  known  as  functtonal  dependency 
analysis.  We  analyzed  information  flows  between  functions  to  ensure  that  information  required 
as  input  to  one  function  is  available  as  output  from  another  function  within  the  decomposite. 

As  each  high  level  function  is  decomposed,  we  analyzed  Hs  subfunctions  in  terms  of  their 
dependency  on  one  another.  In  other  words,  each  subfunction  must  either  provide  information 
to,  or  receive  information  from,  another  subfunction  of  the  same  parent  function.  If  this 
criterion  is  not  met  the  validity  of  the  decomposition  should  be  questioned. 

This  first  step  ensures  dependencies  between  subfunctions  under  each  parent  function. 
We  then  analyze  dependencies  between  functions  at  a  particular  level  of  the  decomposition;  i.e. 
aN  level  1  functions  are  analyzed,  then  all  level  2  funcfions,  etc.  This  process  helps  to  attain  a 
consistent  level  of  detail  in  the  functional  model.  Appendix  A  contains  the  fun^ional  dependency 
dfograms  used  to  validate  the  ISP  Functional  Model.  To  get  the  detailed  definitions  of  the 
functions  at  aH  the  levels  of  the  model,  contact  the  Systems  Division. 
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Figur*  3*2.  NSWCDD  Functional  Decompoaition  Diagram 


3.3.2  Data  Modal 

The  data  model  developed  during  ISP  represents  the  major  categories  of  information 
(entity  types)  that  are  important  to  NSWCDD.  The  model  is,  therefore,  relatively  high  level, 
but  represents  the  overall  character  of  the  business  of  NSWCDD.  Later  stages  of  the 
methodology  will  add  significant  detail  to  the  model  and  will  transform  the  logical  data  model  to 
physical  database  design. 

We  used  entity-relationship  (E-R)  modeling  to  develop  the  data  nHxiel.  E-R  modeling 
"involves  identifying  things  of  importance  in  an  organization  (entities),  the  properties  of 
those  things  (attributes),  and  how  they  are  related  to  one  another  (relationships) The 
objectives  of  E-R  modeling  can  be  summarized  »  follows  to: 

a  provide  an  accurate  representation  of  the  Information  needs  of  the  enterprise, 
which  can  be  used  to  guide  development  of  new  or  improved  systems 

b.  provide  a  model  that  is  independent  of  any  particular  data  storage  or  access 
method  allowing  objective  implementation  decisions  to  be  made 
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The  data  model  is  represented  in  an  entity-relationship  diagram  (ERD).  Appendix  B 
contains  supplemental  information  about  the  syntax  and  semantics  of  E-R  (fiagramming  that  may 
be  he^ui  for  the  reader  unfamiliar  with  ERD  constructs.  The  appendix  contains  the  complete 
data  model,  as  defined  by  the  ISP  project.  The  data  model  consists  of  48  entity  types. 

Data  integrity  rules  can  be  built  into  the  database  implementation  rather  than  into  every 
application  that  uses  the  data.  This  abiiity  provides  a  significant  benefit  by  reducing  the 
complexity  of  applications.  Reducing  com^xity  lessens  the  maimenance  the  rules  require  and 
increases  the  quality  of  the  data  used  by  the  organization.  Entity  relatfonsh^s  modeling^  by  the 
rigorous  definition  of  relationships  between  entities,  provides  a  means  for  ttie  incorporation  of 
these  rules  into  the  data  modei. 


3.3.3  Function/Entity  Type  Interaction 

As  we  developed  the  functional  and  data  models,  consideration  was  given  to  how  the 
functions  and  entity  types  interact;  i.e.  which  functions  perform  create,  deiete,  update,  and  read 
operations  on  the  data.  We  documented  the  information  in  an  association  matrix,  which  is 
sometimes  cailed  a  CRUD  chart.  The  matrix  lists  the  lowest  level  functions  (processes)  in 
rows,  the  entity  types  in  columns,  and  records  either  a  C,  R.  U,  or  D  in  the  appropriate  cell  to 
indicate  the  kind  of  interactions  that  can  take  place.  By  convention,  only  a  single  interaction 
code  is  entered  into  a  cell,  so  a  hierarchy  of  interactions  is  used. 

C  in  a  cell  means  the  process  may  create,  delete,  update,  and  read  that  entity  type 
0  means  the  process  may  deiete.  update,  and  read  the  entity  type 
U  means  the  process  may  update  and  read  the  entity  type 
R  means  the  process  may  only  read  the  entity  type 


Figure  3-3  shows  a  partial  CRUD  matrix  to  introduce  these  concepts;  Appendix  C 
contains  the  complete  ISP  CRUD  matrix. 

The  first  thing  that  we  should  observe  about  the  matrix  is  that  it  is  not  a  very  sparse 
matrix;  i.e.,  many  of  the  cells  contain  entries.  This  is  a  strong  indication  of  why  an  applications 
environment  will  not  work  for  NSWCDD.  In  an  applications  environment,  several  of  the 
functlorrs  would  be  grouped  together,  and  the  data  that  they  need  would  be  defined.  A  database 
containing  the  required  data  would  be  designed  and  developed.  Then  another  set  of  functions 
would  be  chosen  and  their  required  data  would  be  defined.  The  problem  is  that  this  group  of 
defined  data  needs  will  almost  surely  contain  data  already  defined  and  processed  by  the  first  set 
of  functions.  If  the  data  is  repeated  for  both  sets  of  func^s,  an  enormous  maintenance 
problem  arises  as  b(^  data  stores  must  be  populated  and  updated.  An  enormous  data  consistency 
and  reliebiNty  problem  will  also  arise  as  the  updates  to  ^e  data  go  out  of  synchronization, 
updMes  and  corrections  are  only  made  to  one  set,  «id  the  other  is  missed,  etc.  The  only  solution 
is  a  logically  defined  corporate  database.  In  this  scenario,  all  data  tor  toe  enterprise  is  managed 
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Figure  3>3.  Partial  Function/Entity  Type  Aaaoclation  Matrix 


as  if  it  were  one  large  database.  The  functions  that  need  the  data  will  use  the  one  logical 
definition  of  the  data.  This  is  not  to  say  that  there  wiH  be  one  enormous  physical  database.  The 
implementation  strategy  could  be  handted  several  ways.  The  point  is.  however,  that  for  the 
developers  of  an  application  the  data  is  defined  and  the  definition  and  usage  rules  are  maintained 
centrally.  When  the  tecfmology  catches  up  to  the  concepts,  the  application  developer  would  not 
need  to  know  physically  where  the  data  resides,  but  would  only  tell  the  data  repository  system 
that  certain  pieces  of  d^  were  needed  to  be  processed.  The  system  would  be  a  transparent 
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conduit  between  the  application  and  the  data  stores  themselves.  The  system  would  enforce 
consistency  and  integrity  rules,  as  well  as  access  privileges. 

The  second  aspect  of  the  non-spardty  of  the  matrix  deals  with  implementation  issues.  If 
we  were  in  a  straight  technology-driven  implementation  environment,  we  would  move  toward 
first  defining  and  implementing  those  entity  types  foat  are  used  by  the  most  functions.  Even  in  a 
pure  technology-driven  scenario  there  would  be  problems.  Instead  we  will  be  defining  and 
implementing  the  entity  types  and  functions  that  will  permit  us  to  satisfy  the  most  important 
needs  of  NSWCDD.  This  will  create  more  problems  about  how  to  preliminarily  define  and 
implement  our  systems.  For  example,  the  entity  type  called  Directive  is  used  by  almost  every 
function  on  the  matrix.  Without  access  to  the  information  represented  by  this  entity  type, 
almost  no  function  could  be  properly  implemented  in  practice.  The  problem  is  that  we  need  to 
implement  in  chunks  of  functions  and  their  corresponding  entity  types,  but  the  full  use  of  a 
particular  entity  type  may  not  be  known  until  several  chunks  later.  We  should  remember  at 
this  point,  that  automation  is  not  assumed.  Access  to  an  entity  type  does  not  mean  that  the  entity 
type  must  be  maintained  in  an  automated  state. 


3.3.4  Data  Sharing  and  Distribution  Requirements 

The  functional  model  is  developed  without  regard  for  organizational  structure.  Its 
purpose  is  to  represent  a  purely  functional  view  of  NSWCDD,  which  should  be  relatively  stable 
over  time.  Once  the  function  and  data  models  have  been  developed,  however,  consideration  of 
organizational  structure  and  physical  location  can  lead  to  inferences  about  how  data  can  be 
shared  and  distributed  to  optimize  support  of  NSWCDD's  business. 

We  analyzed  the  functions  and  data  within  the  context  of  the  organizational  structure. 
Matrices  show  associations  of  processes  and  data  with  the  organizational  units  that  use  them. 
Figure  3-4  presents  a  matrix  that  associates  the  lowest  level  functions  from  the  functional 
decomposition  with  the  organizations  that  perform  them.  We  defined  the  organizational 
structure  only  down  to  the  department  level,  which  is  a  level  sufficient  for  ISP  purposes.  Finer 
analytical  granularity  will  occur  during  the  analysis  stage  of  the  methodology.  The  matrix 
indicates  the  distribution  of  business  functions  throughout  NSWCDD  and  shows  that  many 
functions  are  performed  by  all  or  nearly  all  the  organizations  considered.  As  might  be  expected, 
functions  dealing  with  planning,  raviaw  and  evaluation,  management  of  resources,  and  safely  and 
security  appear  in  the  matrix  as  the  responsibility  of  all  organizational  units. 

We  determined  an  organization's  responsibility  for  data.  We  used  the  Function  / 
Organizational  Unit  matrix  to  identify  which  functions  an  organization  performs.  We  then 
determined  how  those  functions  interact  with  entity  types  by  using  the  CRUD  matrix.  The  Entity 
Type/Organizational  Unit  matrix,  as  shown  in  Figure  3-5,  shows  responsibility  by 
organization  for  the  creation  or  update  of  the  data  entities. 
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Figure  3*5.  Entity  Type/Organizational  Association  Matrix 
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3.4  Sharing  and  Distribution  Conciusions 

The  Entity  Type/Organizational  Unit  matrix  reveals  that  the  following  entity  types  are 
used  by  every  organization  considered  in  this  analysis: 

DIRECTIVE  BUDGET 

PERSON  ORGANIZATION 

ACTION  REQUEST  RNANCIAL  TRANSACTION 

PLANT  PROPERTY  TECHNICAL  INFORMATION 

INTEROFFICE  COMMUNICATION 

Therefore,  a  significant  requirement  exists  to  share  these  data  across  organizational 
units.  The  matrix  in  Figure  3-5  reflects  only  the  organizations'  responsibility  for  creation  and 
update  of  entity  types.  Consideration  of  an  organization's  need  to  read  entity  types  would 
demonstrate  an  even  greater  requirement  for  data  sharing. 

Observations  can  be  made  relative  to  these  matrices.  For  example,  the  Function/ 
Organizational  Unit  matrix  in  Figure  3-4  shows  no  overlap  of  the  primary  functionality  of  the 
Comptroller  Department  (M)  and  the  Supply  Department  (S).  However,  the  Entity  Type/ 
Organizational  Unit  matrix  in  Figure  3-5  clearly  shows  that  these  two  departments  need  to 
share  data  in  the  execution  of  their  fiduciary  responsibilities;  e.g.,  PROVIDER,  PROCUREMENT 
LINE  ITEM,  and  PLANT  PROPERTY.  Analysis  of  these  matrices  will  help  in  the  future  analysis 
and  development  of  systems  to  ensure  that  the  right  players  are  enlisted  for  the  client  teams. 

Figure  3-6  shows  the  geographical  dispersion  by  organizational  units.  It  shows  that 
nearly  all  departments  have  contingents  at  the  White  O^  Maryland  and  Dahlgren  Virginia  sites. 
Relatively  small  contingents  at  the  remote  sites;  i.e..  Wallops  Island  Maryland,  Ft.  Monroe 
Maryland,  Ft.  Lauderdale  Florida,  will  also  require  service  and  will  therefore  have  an  influence 
on  the  definition  of  the  Technical  Architecture.  Base  consolidation  and  realignment  initiatives 
altered  the  geographical  locations  in  which  NSWCDD  operates.  The  ISP  established  an 
architectural  baseline  for  NSWCDD  prior  to  the  consolidation.  The  baseline  will  need  to  be 
changed. 
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CHAPTER  4 

SYSTEMS  ENVIRONMENT 


4 . 1  Current  Business  Systems  Environment 

NSWCOD's  current  business  systems  environment  is  typical  of  those  found  in 
organizations  still  in  the  early  stages  of  data  processing  evolution.^  NSWCDD  has  over  100 
stand-alone  business  systems  running  on  different  platforms  with  little  automated  exchange  of 
data.  NSWCDD  does  have  a  large  office  automation  system,  which  is  the  official  information 
media  for  NSWCDD.  Specialized  interfaces  between  it  and  some  of  the  business  systems  have 
been  developed,  which  permit  reports  from  a  business  system  to  be  distributed  via  the  e-mail 
capabilities  of  the  office  automation  system.  Some  NSWCDD  organizations  have  instalied  their 
own  local  area  networks,  which  are  not  very  compatible  with  the  official  office  automation 
system.  A  look  at  some  of  the  forces  that  shaped  this  environment  t  M  only  provides 
understanding  of  how  we  got  where  we  are,  but  also  suggests  ways  we  :an  evolve  to  meet  present 
and  future  needs. 

Early  automated  data  processing  was  primarily  concerned  with  providing  applications  to 
reduce  the  cost  of  executing  business  procedures.  For  this  reason,  and  because  of  the  limited 
capabilities  of  information  technology,  information  systems  tended  to  be  limited  to  automation  of 
the  existing  manual  procedures.  Functional  requirements  of  a  particular  operational  segment  of 
the  enterprise  drove  the  design  of  these  systems.  For  example,  the  comptroller  might  automate 
the  payroll  or  the  supply  organization  might  automate  stock  control.  They  tended  to  be 
restricted  to  meet  a  rather  narrow  set  of  needs.  For  the  most  part,  connectivity  between 
systems  did  not  exist  and  systems  were  certainly  not  designed  to  share  data  with  other  systems. 
Systems  with  these  characteristics  are  referred  to  as  'Verticar  systems.  Data  related 
problems  that  arise  from  such  a  systems  environment  were  addressed  in  Sections  3.1  and  3.3.3. 

The  vertical  nature  of  NSWCDD's  systems  environment  is  evident  in  the  difficulty 
associated  with  sharing  data.  Data  sharing  between  systems  usually  requires  creation  of  extract 
files,  data  format  conversions,  and  significant  manual  editing  to  complete  the  task.  Clients  get 
data  in  the  form  of  hardcopy  reports  that  offer  little  flexibility  in  either  format  or  content. 

Another  important  characteristic  of  our  current  systems  environment  is  the  high  cost  of 
maintaining  the  existing  systems.  Since  NSWCDD's  current  system  environment  is  a  product  of 
years  of  automating  processes  and  procedures,  one  could  expect  it  to  be  characterized  by  high 
maintenance  cost.  Figure  4-i  depicts  the  widely  acknowledged  statistic  that  70%  of  the  total 
life-cycle  cost  of  information  systems  goes  to  maintenance.  A  closer  look  at  this  statistic 
reveals  that  only  about  20%  of  that  cost  is  applied  to  corrective  maintenance;  i.e.,  fixing  coding 
errors.  Nearly  80%  is  applied  to  adaptive  maintenance;  i.e.,  enhancements  to  the  systems  to 
satisfy  additional  requirements  of  the  clients.  Older  systems  often  show  degradation  in 
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maintainability  over  time.  The  move  to  IE  supported  by  CASE  tools  is  to  reduce  the  life-cycle 
costs  of  information  systems  in  corrective  maintenance.  The  move  is  also  to  produce  systems 
better  meeting  client  needs  and  thereby  reducing  the  adaptive  maintenance  costs  as  well.  A 
tenet  of  the  IE  methodology  is  that  by  designing  systems  around  the  data  that  changes  the  least 
often,  we  will  have  a  more  stable  and  flexible  systems  environment. 


Figure  4-1.  Information  Systems  Life-cycle  Cost  Distribution 


4.2  Defining  a  New  Business  Systems  Environment 

Evolving  to  a  new  business  systems  environment  will  require  management  of 
information  as  a  corporate  resource.  This  environment  will  be  characterized  by  systems  that 
share  data  with  other  systems  through  corporate  databases.  Data  will  be  created  once  at  the 
source  and  then  used  wherever  needed  throughout  NSWCDD.  The  new  systems  environment  also 
supports  the  information  needs  of  the  whole  enterprise,  in  addition  to  supporting  the  functional 
requirements  of  particular  business  areas.  The  objectives  of  defining  a  new  business  system 
environment  are  to: 

a  show  the  likely  future  environment  of  systems  and  databases  that  will  meet  the 
overall  needs  of  NSWCDD 

b.  provide  a  basis  for  planning  of  future  analysis  and  systems  development  to 
ensure  compatibility  between  systems  and  with  databases 

c.  provide  a  basis  for  determining  and  revising  the  technical  architecture 

Without  such  an  environment,  we  will  continue  to  build  systems  and  databases  in  isolation  and 
perpetuate  the  problems  of  redundant  data  and  complex  data  exchange  mechanisms.  The  goal  of 
this  effort  is  in  effect  a  framework  for  the  future  development  of  business  systems.  It  is 
derived  from  the  Information  Architecture  but  adds  practical  factors  such  as  mandated  systems, 
available  technology,  and  business  policies.  As  i^iortties  change  or  tedinologies  change,  we  will 
be  better  able  to  make  intelligent  decisions  in  response  to  those  changes.  Being  in  a  business 
system  environntent  permits  us  to  understand  the  interdependencies  needed  for  proper 
sequencing  and  scoping  of  the  subsequent  analysis  and  development  projects. 


4-2 


NSWCDD/TR-92/47 


4.3  Businas*  Systsms  Architsctur* 

Chapter  3  presented  the  Information  Architecture  which  lays  out  the  information 
rec^irements  of  NSWCDD.  The  objective  of  this  section  is  to  present  a  view  of  the  systems  and 
databases  needed  to  satisfy  those  information  requirements.  This  view  of  the  target  systems 
environment  is  called  the  Business  Systsms  Architecture.  It  will  senre  as  a  basis  for 
information  system  development  in  the  future.  The  benefits  from  developing  a  business  systems 
architecture  are  as  follows: 

a  provides  a  means  to  control  data  redundancy  and  flow  between  processes 

b.  provides  a  means  to  scope  and  prioritize  the  requiremems  established  by  the 
information  architecture  into  development  projects  that  can  be  managed  with 
available  resources 

c.  provides  guidance  to  the  definition  of  the  technical  architecture 

The  Business  Systems  Architecture  is  developed  from  the  data  entity  types  and  processes 
of  the  Information  Architecture.  We  need  to  understand  the  interrelationships  between 
functions,  between  entity  types,  and  between  functions  and  entity  types.  We  generated  a 
hierarchy  of  visual  representations  to  show  the  various  relationships.  The  diagrams  help 
validate  the  relationships,  which  are  codified  in  the  CASE  tool.  Figure  4-2  shows  the  diagram 
for  the  high  level  function  of  Financial  Management.  Figure  4-3  shows  the  diagram  for 
Administer  Funds  within  Financial  Management,  it  has  two  nx>re  processes.  The  later  analysis 
is  performed  at  this  lowest  level;  e.g..  Accept  &  Allocate  Funds.  Appendix  A  discusses  how  to 
read  these  diagrams  and  contains  the  full  set.  Clustering  of  CRUD  interactions  between 
processes  and  entity  types  produces  groups  of  entity  types  and  groups  of  processes.  The  gro^)S 
are  referred  to  as  natural  data  stores  and  natural  business  systems,  respectively.  Each  of  these 
groups  will  be  dfocussed  below.  Clustaring  is  based  on  the  mathematical  process  of  affinity 
analysis,  which  calcuiates  the  similarity  between  pairs.  We  performed  separate  clusterings  for 
entity  types  and  for  processes. 

The  lEW  tool  performs  the  affinity  calculations  using  the  interaction  entries  stored  in 
the  CRUD  mahix  shown  in  Appendix  C.  The  tool  produces  a  report  of  the  computed  affinity 
values.  Natural  business  systems  are  then  defined  as  groups  of  processes  with  high  affinity; 
i.e.,  they  support  a  highly  related  set  of  functions  that  are  all  interdependent  and  are  all 
Involved  with  basically  the  same  entity  types.  Likewise,  natural  data  stores  are  defined  as 
groups  of  entity  types  that  have  high  aff^  for  one  another.  We  define  business  areas  by 
bringing  together  ooHections  of  natural  data  stores  wd  natural  business  systems.  Business 
areas  estitoiish  the  boundaries  for  projects  that  will  undergo  further  analysis. 

Without  the  use  of  a  CASE  tool,  affinity  malysis  would  not  be  performed.  Affinity 
calcuiations  are  made  for  aR  permutations  of  p^  of  objects.  The  information  architecture 
contains  48  entity  types  and  61  processes.  The  sheer  volume  of  calcuiations  would  make  thte 
kind  of  analysis  practically  impossible  to  perform  without  automated  support. 
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Figure  4>2.  Financial  Management  Diagram 


ADMINISTER  FUNDS 


Figure  4*3.  Adminiater  Funda  Diagram 
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Figure  4-4  shows  that  almost  6000  calculations  were  required  for  each  iteration  of  the 
affinity  analysis. 


4.3.1  Data  Stores 

A  data  store  is  a  collection  of  information  that  can  be  repeatedly  and  non-destructively 
accessed.  Data  stores  can  be  either  automated  or  manual,  and  can  consist  of  a  single  entity  ty^ 
or  several  entity  types.  Natural  data  stores  are  a  product  of  the  clustering  technique  which 
groups  together  highly  related  entity  types.  These  data  stores  are  natural  In  the  sense  that  the 
affinity  that  exists  between  entity  types  is  based  on  their  use  only.  We  do  not  consider  technical 
or  political  factors  that  may  influence  the  groi^ting  of  data.  Figure  4-5  displays  the  Entity  Type 
within  Data  Store  Table  which  indicates  the  grouping  of  entity  types  into  natural  data  stores. 
Future  analysis  will  divide  these  general  categories  into  much  finer  detail.  Appendx  D  shows 
the  data  flow  diagrams. 


4.3.2  BuainMa  Syatema 

A  business  system  is  a  ooliection  of  processes  that  support  a  particular  functional  area 
of  NSWCDD.  Uke  data  stores,  systems  may  be  either  automated  or  manual.  Again,  the  ot^ective 
is  to  identify  natural  business  systems;  i.e.,  groups  of  processes  that  have  interactions  with  the 
same  entity  types.  Natural  business  systems  are  identified  based  on  the  affinity  between 
processes  and  without  consideration  of  technical,  organizationai  or  political  factors.  The 
natural  business  systems  and  the  processes  that  make  them  up  appear  in  the  Process  within 
Bustetess  System  Table  in  Figure  4-6.  We  have  split  the  lower-level  furx^ns  from  their 
parent  ftinctions  and  regrouped  them  aooordktg  to  their  use  of  the  entity  types.  The  business 
systems  now  no  longer  match  the  functionai  decomposition  depicted  in  Figure  3-2.  A  single 
business  system  may  cross  several  tof>-level  ftmctions.  For  example,  the  Business  System 
caNed  "Review  &  Evaluation*  has  tfiree  processes  assodated  with  it.  Each  process  comes  from  a 
different  high  level  function,  i.e.,  Monitor  Program  from  the  Product  &  Service  Department 
kinction;  Analyze  &  Review  Ftoiance  from  the  FlnancW  Management  function;  and  Review 
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Figurt  4*5.  Entity  Typn  wKbln  Data  Stora  TaMa 
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Organizational  Effectiveness  from  the  Organizationai  Management  function.  Sometimes  a  single 
business  system  relates  nveii  to  the  functionfiri  decomposition. 

All  natural  business  systems,  by  virtue  of  the  way  the  methodology  defines  them,  are 
comprised  of  processes  that  aeate  data.  These  processes,  in  many  cases,  are  the  r^ponsbility 
of  a  single  organizational  unit  as  shown  in  Figure  3-4.  The  data  they  create  will  support  a  wide 
range  of  information  needs,  from  low-level  transaction  processing  to  high-level  strategic 
decision-making.  Business  systems  must  create  data  to  support  al  these  categories.  In 
planning  for  information  systems  to  support  NSWCDD.  are  determine  the  categories  of 
information  needs  for  which  business  systems  will  need  to  provide  supporting  data. 


4.3.3  Business  Areas 

Business  areas  are  simply  collections  of  entity  types  and  processes  that  should  be 
analyzed  together  in  greater  detail.  We  identified  business  areas  by  bringing  together  tiie 
natural  data  stores  and  natural  business  systems  defined  by  the  clustering  process.  Appendix  C 
contains  a  CRUO  matrix  whose  rows  and  columns  have  been  re-ordered  to  reflect  the  clustering 
of  natural  data  stores  and  buskiess  systems.  Business  areas  are  indicated  in  this  matrix  as  the 
bold  line  boxes.  These  groupings  of  entity  types  and  processes  define  the  boundaries  of  the  BAA 
projects  to  be  urKfertaken  in  the  next  phase  of  the  methodology.  The  NSWCDD  ISP  project 
identified  10  business  areas.  Figure  4-7  presents  these  business  areas  and  the  business 
systems  falling  in  each  area.  Remember  that  the  wialysis  projects  will  use  these  processes  as  a 
starting  point  and  will  add  considerable  detail  to  the  process  decomposition. 

Figure  4-8  presents  four  categories  of  information  use  (transactional,  monitoring  and 
control,  planning  and  analysis,  and  strategic).  It  maps  the  business  systems,  grouped  by  the 
business  area  they  support,  onto  these  categories.  As  the  figure  indicates,  none  of  the  systems 
are  solely  transactional  in  nature.  They  aH  will  support  information  needs  beyond  the 
transactional  level  and  wW.  therefore,  provide  data  to  broad  segments  of  NSWCDD. 

A  representation  of  the  business  systems  architecture  is  presented  in  Figure  4-9.  Each 
of  the  10  business  areas  is  shown  in  a  fonriat  that  indfoates  the  scope  of  the  business  area's 
involvement  with  data.  The  figure  can  be  thou(H>t  of  as  a  pictorial  representation  of  the  CRUD 
matrix  in  that  K  differentiates  between  primary  interactions  (creates)  and  secondary 
interactions  (updates  and  reads).  Within  each  l^siness  area  diagram,  the  expected  business 
systems  are  shown  in  a  box  color  coded  for  that  busfoess  area. 

Within  each  business  area  dfogram,  we  also  show  data  stores.  A  data  store  is  oon^xsad  of 
one  or  nwre  entity  types,  as  shown  in  Figure  4-5  dbove.  We  have  spatiaNy  organized  the  data 
stores  based  on  where  the  data  store  is  created  and  how  the  business  area  uses  the  data;  i.e., 
creates  or  reads  the  data.  We  have  divided  the  data  stores  into  three  groups;  (1)  created  by  the 
business  area.  (2)  created  by  anottier  business  area  and  updated  by  the  business  area,  and  (3) 
read  by  the  businMS  area.  The  first  group  is  to  the  left  of  the  colored  box,  under  the  heading 
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'Primary  Interactions.'  These  data  stores  fall  within  the  bounds  of  the  business  area.  In  other 
words,  these  are  the  data  stores  that  are  created  within  the  business  area.  These  data  stores  are 
the  same  coior  as  the  business  systems  box  to  indicate  their  dose  affiliation  with  these  systems. 

The  second  group  is  to  the  right  of  ttte  shaded  box.  These  data  stores  are  created  within 
some  other  business  area,  but  are  updated  by  functions  within  the  business  area  being 
considered.  The  business  area  that  creates  a  particular  data  store  can  be  identified  by  locating 
the  data  store  in  the  'Primary  Interactions*  section  of  some  business  area  diagram.  The  color 
coding  simplifies  this  search.  For  example,  to  find  the  business  area  that  creates  the  data  store 
Organizations  (colored  light  blue)  simply  look  through  the  business  area  diagrams  and  find 
the  business  system  box  of  the  same  color.  This  reveals  the  data  store  Organizations  listed  as 
a  primary  interaction  under  the  business  area  ORGANIZATION  MANAGEMENT. 

The  third  group  is  beiow  the  coiored  business  systems  box.  These  are  all  the  data  stores 
from  which  the  business  area  needs  to  read  data.  Oc^rrences  of  secondary  interactions  -- 
groups  two  and  three  --  indicate  requirements  to  share  data  between  business  areas.  This 
figure  is  a  graphic  illustration  of  why  developing  systems  in  an  applications  paradigm  will  not 
suffice  in  our  environment.  The  data  stores  need  to  be  independent  of  individual  applications  of 
the  business  areas  and  they  need  to  be  controlled.  We  must  support  these  needs  to  efficiently  and 
effectively  maintain  systems,  especially  in  an  environment  of  mandated  systems. 

Although  the  diagrams  in  Figure  4-9  indicate  information  dependencies  between 
business  areas,  more  detail  is  needed  to  understand  the  actual  interplay  between  business 
systems  and  data  stores.  The  data  flow  diagrams  provide  this  detail  as  shown  in  Appendix  D.  In 
Appendix  D,  each  business  system  is  presented  as  a  data  flow  diagram,  which  displays  the 
processes  that  m^e  up  the  system  and  the  flow  of  data  between  processes.  The  diagram  shows 
data  flows  to  and  from  other  business  systems,  as  weH  as  to  and  from  agents  outside  the 
enterprise. 


4.4  Businesa  Area  Support  for  Information  Needs 

Constraints  on  people,  money,  and  time  prevent  detailed  analysis  of  all  10  business 
areas  at  once,  so  a  priority  for  analysis  projects  must  be  established.  Chapter  7  deals  with  the 
Information  Strategy  and  will  identify  tfw  priority  projects.  This  section  wiii  iay  some  of  the 
foundation  for  the  strategy  by  considering  the  business  areas  from  an  information  needs  point  of 
view.  This  assessment  will  then  become  one  of  the  evaluation  criteria  used  to  formulate  the 
Information  Strategy. 

Ideally,  business  areas  should  be  ranked  according  to  their  support  for  the  critical 
success  factors  of  the  enterprise.  In  the  absertce  of  formal  critical  success  factors  for  NSWCDD, 
the  ISP  project  teams  identified  a  set  of  information  needs  that  might  be  considered  critical  to 
Center  operations.  Identifying  critical  needs  is  no  trivial  task  given  the  volume  of  requirements 
documented  during  ISP.  In  fact,  through  interviews  with  clients,  reference  team  workshops. 
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and  analysis  of  existing  documentation  over  600  information  needs  were  identified.  Appendix  E 
gives  the  list  of  source  documentation  used.  By  abstracting,  summarizing,  and  eliminating 
redundancies,  87  information  needs  were  selected  to  assist  in  the  ranking  of  BAA  prqects. 

The  histogram  in  Figure  4-10  shows  the  number  of  information  needs  addressed  by  each 
business  area.  As  indicated  by  the  histogram,  the  largest  information  needs  are  addressed  by 
three  business  areas:  Organization  Management,  Financial  Management,  and  Acquisition  and 
Material  Management.  The  histogram  information  was  derived  from  the  matrices  in  Figure  4- 
1 1  on  the  foilowing  pages.  These  matrices  relate  the  individual  information  needs  to  the 
business  areas  that  address  them.  The  information  needs  in  the  rows  of  the  matrix  have  been 
arranged  to  group,  needs  by  business  area  to  aid  readability  and  understanding.  No  attempt  has 
been  made  to  identify  the  most  important  information  needs  and  no  order  of  importance  is 
implied  by  the  order  of  the  rows.  The  diagrams  in  Figure  4-9  show  the  great  overlap  in  data 
store  usage  by  the  business  areas.  Hence,  the  development  of  any  of  these  three  primary 
business  areas  will  probably  require  at  least  some  preliminary  definition  and  development  of 
data  stores  outside  the  business  area,  particularly  from  the  Product  Development  business  area. 


Figure  4-10.  Business  Area  Support  for  Information  Needs 
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CHAPTER  5 

TECHNICAL  ARCHITECTURE 


The  Technical  Architecture  is  the  last  major  piece  of  the  puzzle.  It  describes  the 
mixture  of  hardware,  software,  and  communications  facilities  needed  to  support  the  other 
architectures:  Information  and  Business  Systems.  At  the  ISP  phase  of  the  program,  the 
Technical  Architecture  identifies  appropriate  technical  components,  which  make  up  the  building 
blocks.  It  does  not  specify  actual  products.  The  objectives  of  this  part  of  the  planning  are  to: 

a  provide  an  overview  of  available  technical  components  and  policies 

b.  identify  technology  trends  that  are  relevant  to  NSWCDD 

The  analysis  encompasses  all  hardware  and  software  facilities  used  for  information  processing 
and  all  communications  facilities  used  for  transmission  of  information,  except  the  telephone  and 
naval  messages  facilities. 


5.1  Current  Technical  Environment 

The  technical  environment  currently  in  place  at  NSWCDD  consists  of  a  wide  range  of 
hardware  and  software  components  supplied  by  a  number  of  vendors.  Anchored  by  the  Control 
Data  Corporation  (CDC)  mainframes,  the  environment  includes  VAX/VMS  systems,  various  UNIX- 
based  minicomputers,  workstations,  terminals,  personal  computers  -•  both  MS-DOS  and 
Macintosh.  NSWCDD  is  supported  by  several  communications  networks,  including  NSWCDD 
Wide  Area  Network  (CWAN)  for  terminal  to  host  connectivity,  and  NSWCNET,  a  host-to-host 
network  based  on  the  DOD  standard  Internet  Protocols.  In  addition,  to  the  centrally  managed 
networks,  several  work  groups  have  installed  Local  Area  Networks  (LANs)  for  their  personal 
computers  and  workstations,  and  some  programs  have  tied  together  their  VAXA^MS  complexes. 

During  the  ISP,  NSWCDD  was  physically  distributed  among  the  principal  sites  at 
Dahlgren,  Virginia,  and  White  Oak,  Maryland,  and  four  remote  sites  at  Wallops  Island,  Virginia; 
Brighton  Dam,  Maryland;  Ft.  Monroe,  Virginia;  and  Ft.  Lauderdale,  Florida.  Figure  5-1 
highlights  these  locations  and  indicates  the  centrally  controlled  technical  facilities  at  each  site. 

Figure  5-2  represents  NSWCDD's  current  technical  environment  in  a  format  that 
groups  technical  facilities  -  hardware,  software,  and  communication  networks  --  according  to 
the  information  technology  areas  they  serve  and  the  degree  to  which  they  are  shared.  Four 
technology  areas  are  pertinent  to  NSWCDD: 

a  Business  Transaction  Processing 

b.  Management  Information  Services 

c.  S&E  Computing 

d.  Office  Automation 


5-1 


NSWCDD/TR-92/47 


By  looking  vertically  along  any  of  these  technology  area  columns,  one  can  determine  the  kinds  of 
technical  f^lities  supporting  that  area.  Business  transaction  processing  refers  to  systems 
that  process  detail  data;  e.g..  the  financial  management  system  processing  accounts  payable 
reco^s  or  payroll  records.  The  management  information  services  area  will  use  much  of  the 
same  data  as  the  transaction  systems,  but  will  be  interested  in  it  after  the  detail  data  has  been 
processed;  e.g..  funds  expended  to  date  for  a  program.  It  would  also  have  data  not  necessarily 
processed  by  a  business  transaction  system;  e.g.,  milestone  data.  The  Scientific  and  Engineering 
(S&E)  computing  area  encompasses  the  processing  done  in  support  of  the  real  business  of 
NSWCDD.  Office  automation  refers  to  the  tools  at  the  desktop  available  to  each  employee  for  the 
carrying  out  of  their  work.  The  tools  required  would  vary  by  the  employee  and  would  depend 
upon  the  function  each  performs  or  is  performing  at  the  time.  For  example,  word  processing 
tools  are  needed  by  many  employees,  whether  they  work  in  the  technical,  managerial,  or 
support  areas.  Different  data  reduction  tools  might  be  more  applicable  to  engineers  or 
administrative  officers.  Office  automation  also  covers  electronic  mail  and  other  server  areas. 


Figure  5*1.  Locations  of  NSWCDD  Technical  Facilitiee 
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Figur*  5*2.  Current  Technical  Architecture 
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Technical  facilities  are  groi4)ed  within  the  columns  acoorcSng  to  the  typical  usage  level 
of  the  technology.  For  example.  S&E  mainframes  are  shared  across  NSWCDD,  but  a  particular 
personal  computer  is  usually  used  as  an  unshared  component.  One  of  the  challenges  of  the 
NSWCDD  environment  occurs  at  the  Single  Unit  level,  in  the  diagram,  it  would  appear  that 
there  are  separate  workstations  for  business,  SAE.  and  office  automation.  But.  many  clients 
work  in  all  areas  and  the  need  exists  for  each  client  to  have  only  one  device  on  his/her  desk. 
These  same  devices  must  also  be  able  to  tie  into  the  higher  levels  of  technology  usage;  e.g.,  the 
workstation  as  a  terminal  to  the  higher  SAE  computing  powers.  The  current  installed  base  and 
the  need  for  diversity  of  systems  and  workstations  require  a  technoiof^caiiy  challenging 
solution.  This  presentation  of  technical  architecture  helps  the  designer  make  decisions  about 
the  kinds  of  technology  to  apply  to  the  requirements  that  are  inherent  (and  sometimes  unique) 
to  each  information  technology  area. 

A  brief  explanation  of  the  contents  of  Figure  5-2  will  help  us  to  understand  why  certain 
components  appear  where  they  do.  The  large  box  that  appears  in  the  'Shared  Division-wide” 
row  contains  the  SAE  mainframes  and  the  networked  workstations  and  personal  computers. 
These  components  represent  the  central  SAE  computing  facility  and  the  CAD/CAM  facility. 
Currently,  the  CDC  mainframes  are  allocated  to  much  more  than  SAE  computing,  which  is  shown 
by  the  box  spread  into  other  technology  areas.  Business  processing  traditionally  has  been 
supported  on  the  SAE  computing  systems,  and  currently  the  Financial  Management  System, 
Accounts  Payable,  Civilian  Payroll,  Plant  Account  system,  and  many  other  business  applications 
are  run  on  the  mainframes.  NSWCDD's  Office  Automation  systems  consists  of  a  duster  of  UNIX- 
based  minicomputers  that  are  accessed  either  by  terminals  or  by  personal  computers  and 
workstations  running  terminal  emulation  software. 

In  the  'Shared  within  Organization  Unit'  row,  the  box  labelled  'Business  Support 
Systems”  represents  the  systems  that  support  transaction  and  MIS-level  processing  within 
NSWCDD's  support  departments.  Examples  of  these  systems  are  the  Automated  Inventory 
Control  System  (AlCS)  for  the  Supply  Department  and  the  CHRIS  for  the  Personnel  Department. 
Program  Specific  Platforms  represent  systems  whose  primary  purpose  is  to  support  spedal 
requirements  of  technical  programs.  For  example,  AEGIS,  Tomahawk,  and  VLS  programs  have 
such  systems.  These  systems  now  manually  or  semi-automatically  import  some  data  from  the 
financial  systems  operated  for  the  Comptroller  Department. 

Finally,  in  the  'Single  UniT  row  are  the  devices  found  on  the  end-user's  desktop. 
Terminals,  IBM-compatfole  personal  computers,  ranging  in  power  from  the  original  personal 
computers  to  high  end  80486-based  machines,  Macintosh  systems,  and  a  variety  of  engineering 
workstations  comprise  this  component  of  the  environment. 

Although  secure  facilities  are  not  explicitly  identified  in  Figure  5-2,  much  of  NSWCDD's 
processing  is  dassified.  The  CDC  875  computer  is  derScafod  to  classified  processing  and  is 
accessed  via  the  secure  terminal  to  host  SENET  network.  Most  of  the  program  specific  systems 
are  also  used  for  processing  dassified  information.  lack  of  capability  to  shve  information 
more  easily  between  dassified  systems  and  between  systems  that  are  predominantly  dassified 
but  need  to  import  unclassified  information  to  produce  final  products  is  a  large  drawback  to  the 
current  environment. 
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Overall,  NSWCDD’s  current  technical  environment  can  be  characterized  as  decentralized. 
There  Is  no  single,  central  computer  system  that  handes  all  processing  requirements.  There  is 
little  adherence  to  standards  for  interoperability.  Instead,  an  environment  has  evolved  in  which 
many  host  computer  platforms  exist  and  in  which  most  processing  occurs  in  terminal  to  host 
mode.  Although  personal  computers  are  prevalent,  they  have  not  been  well  integrated  into  the 
mainstream  processing  operations  and  their  computing  power  has  been  under  utilized. 


5.2  Defining  a  New  Technicai  Environment 

Up  to  this  point,  two  of  the  three  objectives  of  ISP  have  been  addressed.  High-level 
infonnation  requirements  of  NSWCOO  have  been  identified,  and  a  view  of  the  systems  needed  to 
provide  the  information  has  been  established.  The  third  and  final  ot^ective  is  to  identify  the 
kinds  of  technologies  that  might  be  utilized  to  implement  the  systems.  NAVSEA  has  defined  a  top- 
level  technical  architecture^  to  which  it  plans  to  migrate  over  the  next  several  years.  As  a  part 
of  the  NAVSEA  organization,  NSWCDD  will  need  to  conform  to  those  guidelines.  The  guidelines 
present  a  direction  that  meshes  with  the  conclusions  of  this  analysis. 

Uke  NAVSEA.  NSWCDD  requires  information  technology  solutions  that  provide  for 
interoperability  of  products  across  heterogeneous  systems,  portability  of  software,  data 
distributed  across  multiple  locations,  and  systems  that  can  be  scaled  depending  upon  location. 
NSWCDD  has  a  sizeable  investment  in  hardwve,  and  we  would  like  to  re-use  existing  hardware 
where  possible.  Sizing  and  performance  tests  performed  would  seem  to  indicate  that  some  of  our 
existing  suite  of  hardware  is  not  as  capable  as  we  would  like  for  a  database  environment.  The 
Technical  Architecture  will  satisfy  the  following  objectives: 

a  Adopt  and  implement  open  systems  standards 

b.  Provide  the  most  effective  means  of  managing  the  application  of  infonnation 
systems  technology  to  the  needs  of  NSWCDD 

c.  Achieve  seamless  and  transparent  sharing  of  data  and  applications  across  sites 

d.  Provide  for  the  use  of  common  definitions  of  data  needed  to  meet  NSWCDD 
information  needs,  which  are  consistent  with  higher  echelon  requirements 

a  Achieve  interoperability  of  all  applications  platforms 

f.  Ensure  portability  and  scalability  of  applications  and  infrastructure  software  in 
a  multivendor  environment 

g.  Implement  the  technical  infrastructure  necessary  to  achieve  the  business  and 
IRM  goals  of  NSWCDD  within  constraints  placed  on  NSWCDD 

Some  of  these  objectives  are  beyond  the  current  state-of-the-art  in  information  technology. 
They  wW,  nonetheless,  be  the  basis  on  which  decisions  will  be  made  concerning  the  care  and 


5-5 


NSWCDD/TR-92/47 


feeding  of  the  technical  architecture.  Since  standards  to  support  the  achievement  of  these 
objectives  are  not  fully  implemented,  a  transition  strategy  wiH  be  needed. 


Several  technical  and  philosophicai  trenrte  are  developing  within  the  realm  of 
information  management  that  should  be  considered  in  the  definition  of  a  new  technical 
environment.  Some  of  these  are  presented  below. 

Open  Syeteme  ArchHeeture.  To  break  the  stranglehold  of  proprietary  vendor  solutions,  the 
Government  has  begun  adopting  standards  for  an  open  systems  environment  that  ensures 
interoperability  and  applications  portability  across  muitivendor  platforms.  The  Government 
Open  Systems  Interconnection  Profile  (GOSiP)  became  a  mandatory  specification  for 
Government  computer  and  communications  procurements  in  1990.  GOSIP  is  a  set  of  data 
communications  standards. 

Relational  Database  Management.  This  technology  is  mature,  well  supported  by  vendors, 
and  is  capable  of  satisfying  the  performance  requirements  of  transaction-oriented  systems  as 
well  as  Management  Information  Systems  (MIS)  applications.  Relational  database  technology 
wNI  likely  be  the  defacto  data  management  standard  for  at  least  the  next  decade.  The  capability 
of  distributed  data  management  is  slowly  being  added  to  some  relational  database  systems.  The 
performance  problems  of  distributed  Relationai  Database  Management  Systems  (RDBMS)  are 
significant  in  a  technical  sense.  But,  the  payoff  in  the  maintenance  of  the  databases  themselves 
could  be  large  in  our  geographically  distributed  environment. 

Computer  Aided  Systems  Engineering  (CASE).  CASE  tools  are  now  available  that  can 
automate  the  process  of  engineering  software  systems.  Information  pertinent  to  the  life  cycle  of 
the  systems  can  be  contained  in  CASE  tools.  Details  range  from  requirements,  to  design 
specifications,  to  implementation  details.  AutomaHc  code  generation  from  system  specifications 
promises  to  reduce  development  time,  produce  higher  quality  systems,  and  lower  software 
maintenance  costs.  CASE  will  be  connected  to  a  repository  environment,  which  will  change  the 
processes  for  configuration  management  and  quality  assurance. 

Electronic  Data  Interchange  (EDI).  Based  on  the  X.400  messaging  standard,  this 
technology  provides  a  means  to  electronically  transfer  procurement  data  between  buyer  and 
supplier.  EDI  is  a  proven  cost  saver  in  private  indushy  and  is  beginning  to  take  hold  in  the 
Government  sector.  The  gocri  of  the  CAL^  effort  is  wt  expansion  of  EDI  and  covers  more  than 
messaging  standards;  e.g.,  document  and  graphical  representation  standards. 

Graphical  User  Interfaces  (GUIs).  GUIs  such  as  that  found  on  the  Macintosh  personal 
computer  are  an  emergfog  technology,  which  nudtos  systems  easier  to  use  than  the  tradttiond 
text-based  user  inferfece.  GUIs  take  advantage  of  the  cognitive  abWty  of  people  to  recognize  and 
understand  graphic  symbols  faster  than  they  can  derive  meaning  from  text.  GUIs  are  becoming 
more  feasfoie  as  the  power  of  personal  computers  increases. 
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MultiprocMsor  computers.  Computer  vendors  have  recognized  the  need  for  flexft>le 
hardware  configurations  that  can  grow  in  capabiiity  as  the  customer's  requirements  change. 
Multiprocessor  platforms  that  can  be  configured  to  the  particular  performance  requirements 
and  budget  of  the  customer.  They  provide  scalability  of  applications. 

Imaging  Systems.  Technical  advances  in  scanner  devices  and  large  volume  storage  devices; 
e.g.  optical  disks,  have  made  image  processing  a  feasfole  technology  In  the  management  of 
documentation.  Such  technology  could  be  very  beneficial  in  managing  information  such  as 
personnel  records  and  official  mail  and  messages. 

Downsizing.  An  emerging  trend  in  the  information  industry  is  downsizing.  It  strives  to 
offload  applications  from  the  mainframe  and  allocate  them  to  smaller  machines,  which  offer 
significantly  better  price/performance  ratios. 

Distributed  Computing.  The  essence  of  distributed  computing  is  the  allocation  of  parts  of  an 
application  to  more  than  one  computer.  Each  computer  performs  a  certain  set  of  functions  and 
is  tuned  to  optimize  the  performartce  of  those  functions.  The  use  of  multiple  computers  is  made 
transparent  to  the  erfo-user  through  the  use  of  technologies  such  as  remote  procedure  calls 
(RPCs).  Several  vendors  currently  offer  implementations  of  distributed  computing  based  on 
the  client/server  architecture. 

Object  Oriented  Software.  Software  developed  for  objective  oriented  software  tools;  e.g., 
Ada,  can  often  be  developed  more  rapidly  than  software  dweloped  in  standard  procedural 
languages  Two  large  factors  are  reusability  of  code  and  the  embedcfing  of  business  rules  with 
the  objects.  There  are  definite  trends  in  this  cfirection  with  languages  and  databases  being 
developed  to  support  this  concept.  In  the  private  sector,  the  financial  industry  is  moving  in 
this  direction,  which  is  a  surprise  from  a  normally  conservative  industry. 


5 . 3  Technical  Architecture 

NAVSEA  defined  an  architectural  structure^  for  use  throughout  its  command.  We  will 
foNow  their  guidance.  The  model  is  based  on  the  Information  Systems  Conceptual  Model  defined 
by  the  Open  Systems  Environment  (OSE)  Reforence  Model  and  the  Applications  Portability 
Profile  (APP)  developed  by  NIST.  They  also  used  the  Navy  Communications  Control 
Architecture  (Draft)  and  the  Navy  CALS  Architecture  promulgated  by  OPNAV.  By  following  this 
guidance,  we  will  be  in  synchronization  with  other  Government  and  Navy  efforts. 

The  model  is  presented  in  conceptual  layers  in  Figure  5-3.  This  is  a  variation  of  the 
NAVSEA  model.  The  foNowing  sections  describing  the  model  are  taken  directly  from  the  NAVSEA 
IRM  Plan. 
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A  leered  approach  was  taken  in  establishing  the  model  in  order  that  the  layers  could  be 
atklressed  independently  and  with  minimal  impact  on  each  other.  The  five  layers  of  the 
architecture  are: 

a  Application  Software 

b.  Application  Program  Interface 

c.  Information  Services  Environment 

d.  External  Environment  Interface 

e.  External  Information  Services  Environment 

The  first  layer  in  the  model  is  the  Applications  Software  layer.  This  layer  includes 
programs,  data  and  documentation  to  support  the  information  needs  of  NSWCDD.  The  major 
effort  of  the  NICCS  program  will  lie  in  this  area  as  the  Business  Areas  are  analyzed  and  systems 
either  built  or  procured  to  support  the  functional  and  data  needs  of  NSWCDD. 

The  Application  Program  Interface  (API)  is  intended  to  make  specific  characteristics  of 
the  Information  Services  Environment  (ISE)  transparent  to  the  application  software.  The 
relationship  between  the  Application  Software  layer  and  the  Information  Services  Environment 
through  the  API  is  demonstrated  conceptually  in  Figure  5-3. 

The  ISE  includes  the  collection  of  hardware,  software,  services,  and  facilities  that 
support  the  applications  software.  ISE  will  facilitate  portability  through  services  accessed  by 
the  API.  The  ISE  includes  three  dimensions:  (1)  Major  Services  Areas,  Service  Levels,  and 
Service  Products.  The  Major  Service  Areas  can  be  further  divided  into  Processing  Systems 
Services,  Communications  Senrices,  and  Data  Management  and  Program  Services.  The 
Processing  Systems  Services  includes  the  hardware,  software,  and  facilities  to  operate  and 
administer  the  information  services  of  NSWCDD.  The  second  dimension  of  ISE  is  Service  Levels 
and  Service  Products.  The  ISE  is  directed  at  three  levels  of  usage:  Single  Unit,  Shared  within 
Organizational  Unit,  and  Shared  Divisiotvwide.  Service  Levels  refer  to  the  client  base  to  which 
the  service  is  being  directed,  not  to  the  number  of  people  using  the  service,  nor  to  a  size  or  type 
of  hardware  platform.  The  term  'Organizational  Unif  refers  not  only  to  the  traditional  line 
organizations  but  any  other  grouping;  e.g.,  program  or  project.  In  the  model,  categories  of 
service  products  have  been  identified,  which  will  be  to  deliver  the  services  to  the  client  base. 
The  categories  are  Platforms,  Data  Management,  and  Communications.  These  categories  support 
the  capability,  performance,  and  capacity  needs  of  an  Information  system;  share  applications 
and  data  within  and  among  service  levels;  and  provide  a  uniform  user  interface  that  reflects  a 
high  degree  of  human  engineering.  These  products  will  be  provided  across  all  three  information 
service  levels  and  will  be  the  delivery  mechanisms  for  the  service  areas  identified  in  the  model. 

The  External  Environment  Interface  (EEI)  will  facilitate  interoperability  between  ISE 
and  the  External  Information  Services  Environment.  The  EEI  makes  the  specific  characteristics 
of  the  two  levels  transparent  to  each  other. 

The  External  information  Services  Environment  consists  of  those  system's  elements  and 
technologies  that  are  external  to  NSWCDD.  These  are  services  outside  the  management  and 
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Figur*  5-4.  NAVSEA  Op«n  Systems  Standsrds 
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organizational  purview  of  NSWCDO,  but  which  are  either  to  provide  needed  external 
information  or  are  mandated  for  use. 

We  will  support  the  open  systems  concepts  promulgated  by  the  NIST  and  the  emerging 
OoO  standards.  In  the  latter  case,  standards  include  repositories,  CASE  tools.  CALS,  and  others. 
The  Applications  Portability  Profile.  devel(^)ed  by  NIST,  is  iqxiated  to  reflect  emerging 
standards  in  the  areas  of  the  profile.  NAVSEA  presented  a  suite  of  interim  and  target  standards.^ 
which  are  shown  in  Figure  5'4.  Migration  to  these  standards  must  be  based  on  both  cost 
effectiveness  and  technological  arNances. 

With  an  understanding  of  the  current  technical  environment,  trends  within  the  industry, 
and  the  kinds  of  technology  the  systems  will  require,  a  vision  of  the  future  ter^nical 
architecture  can  take  shape.  Some  components  of  the  current  technical  environment  have  well- 
defined  transition  strategies  already  in  place;  e.g.  S&E  computing  under  E40  auspices.  These 
will  be  presented  in  the  following  discussion  relative  to  the  major  technology  directions 
envisioned  for  NSWCDO. 


5.3.1  Direction  for  Business  Transaction  Processing 

Business  Transaction  Processing  is  moving  toward  a  distributed  On-Line  Transaction 
Processing  (OLTP)  environment.  Oivision-v«4de  accessible  components  will  be  available  for 
applications  with  widespread  utilization  requirements  and  locally  shared  components  will 
address  the  needs  of  support  organizations.  Systems  will  be  based  on  the  Open  Systems 
standards  for  interoperability  and  might  be  implemented  as  PC  LANs,  minicomputer  clusters, 
database  client/server  configurations,  or  perhaps  mainframe  platforms,  depending  on  the 
technical  requirements  and  constraints  on  funding. 

SOL  (Structured  Query  Language)  will  be  employed  to  manipulate  relational  databases. 
Ada  is  mandated  for  new  business  appKcations  by  both  CIM  and  the  DoN.  OoO  has  developed  an 
interface  between  Ada  and  a  relational  daufoase  management  system.  Business  systems 
development  will  be  supported  by  Integrated  CorTq>uter  Aided  Systems  Engineering  (l-CASE) 
tools  working  in  conjunction  with  an  automated  information  repository.  DoD  has  developed  an 
interface  to  a  CASE  tool  that  will  generate  Ada  code.  Neither  of  the  two  DoD  developed  packages 
are  available  for  general  use.  but  some  version  will  probably  become  available  to  meet  the 
needs  of  DoD  in  this  area. 


5.3.2  Direction  for  Management  Information  Services 

MIS  will  transition  to  an  environment  of  distrfouted  relational  database  and  image 
processing  systems  supported  by  centralized  corporate  database  facilities.  Executive  level 
information,  rolled  up  from  the  operational  databases,  will  be  available  in  the  MIS 
environment.  Natural  language  query  capability  and  presentation  graphics  will  be  employed  in 
this  area.  It  is  anticipated  that  platforms  designed  especially  for  database  processing;  i.e., 
database  machines,  wil  be  used. 
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5.3.3  Direction  for  S&E  Computing 

The  technical  transition  strategy  proposed  by  this  plan  is  predicated  on  the  concept  of  off¬ 
loading  Business  Transaction  Processing  and  MIS  functions  from  the  S&E  mainframes  and 
allocating  them  to  technical  facilities  better  suited  to  the  requirements.  This  should  better 
serve  both  the  business  client  and  the  S&E  client  in  the  long  run.  The  future  of  S&E  computing, 
as  defined  by  the  Follow  On  Scientific  and  Engineering  Computer  System  (FOSECS)  project,  will 
be  a  distributed  environment  consisting  of  high-performance  computing  facilities,  desktop 
computing  facilities,  and  visualization  facilities  capable  of  multilevel  (concurrent  classified 
and  unclassified)  processing.  Program  specific  systems  will  still  be  dictated  by  the  particular 
needs  of  the  programs  but  will  probably  be  compliant  with  the  Open  Systems  interoperability 
standards. 

Integrated  CASE  tools  and  optimizing  high-level  programming  languages  will  be  part  of 
the  S&E  software  environment. 


5.3.4  Direction  for  Office  Automation 

Office  automation  will  transition  from  the  centralized  architecture  of  today  to  a 
distributed,  microcomputer-based  architecture.  The  future  architecture  will  shift  much  of  the 
processing  load  onto  the  desktop  devices.  Generic  functions,  such  as  printing  and  file 
management,  will  be  allocated  to  central  components  when  size  warrants,  but  all  other 
functionality  will  be  allocated  to  the  end-user's  personal  computer  or  workstation.  A  suite  of 
commercially  available  software  will  be  integrated  to  provide  the  office  automation 
functionally. 


5.3.5  Direction  for  Data  Communications 

The  data  communications  environment  is  moving  toward  a  multilevel,  division-wide 
network  that  supports  data,  voice,  and  video  services.  It  is  expected  that  for  at  least  the  next 
decade  the  DoD  standard  network  protocols  (TCP/IP)  will  be  supported  and  will  eventually 
coexist  with  the  International  Standards  Organization's  (ISO)  Open  Systems  Interconnection 
(OSI)  protocol  suite.  Lccal  networks  will  connect  distributed  platforms  and  client  devices  to  the 
backbone  network.  The  distributed  computing  requirements  will  drive  the  required  network 
bandwidth  beyond  1  Gigabits/second  (Gbps). 


5.3.6  Direction  for  Desktop  Devices 

The  trend  toward  distributed  processing  will  continue  to  the  desktop  level  as  more  and 
more  power  becomes  available  in  smaller  and  smaller  boxes.  By  the  mid-1990s, 
microcomputers  capable  of  processing  100  million  instructions  per  second  will  be  available 
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and  affordable.  These  machines  will  be  some  250  times  faster  than  the  original  PCs  that  entered 
the  market  around  1980.  High-speed  workstations  featuring  high-resolution  graphics  will 
also  become  prevalent  as  scientists  and  engineers  move  away  from  traditional  terminal-to-host 
processing.  Desktop  devices  will  be  used  more  frequently  as  hosts  in  their  own  right  and  will 
require  host-to-host  networking  to  achieve  data  transfer  rates  consistent  with  their  processing 
speeds.  Desktop  systems  will  likely  transition  from  DOS  as  a  standard  to  OS/2  and  the  UNIX 
operating  systems.  As  encryption  technologies  become  more  cost  effective,  secure  processing  at 
the  desktop  will  become  more  commonplace. 


5.3.7  Representation  of  the  Future  Technical  Architecture 

Figure  5-5  presents  the  future  technical  architecture  in  the  same  format  used  to 
present  the  current  technical  architecture  in  Figure  5-1.  The  figure  reflects,  as  much  as 
possible,  the  directions  for  each  technology  area  as  discussed.  Figure  5-5  represents  the 
technical  architecture  to  which  NSWCDD  is  likely  to  transition  within  the  next  10  years. 
However  budget  constraints,  changes  in  technology,  and  shifting  requirements  will  necessitate 
many  interim  solutions  during  that  period.  The  technical  architecture  to  be  employed  in  the 
near  term  (next  2-3  years)  will  be  strongly  influenced  by  the  need  to  utilize  existing  technical 
facilities. 
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Figure  5-5.  Future  Technical  Architecture 
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CHAPTER  6 

ORGANIZATIONAL  ENVIRONMENT 


6.1  Assessment  of  Existing  Orgsnixation 

The  current  information  management  organization  mirrors  the  current  NSWCDD 
business  systems  organization.  Individual  business  areas  are  supported  in  their  automation 
needs  by  dedicated  teams  and  individuals,  either  within  their  own  organizations  or  from  the 
Systems  Division.  There  are  a  few  examples  of  a  process  and  infrastructure  that  encourages 
common  methods  of  system  development  and  support  across  pertinent  areas.  This,  of  course, 
contributes  to  the  phenomena  described  in  the  earlier  chapters  of  this  report:  vertical  systems 
that  address  the  functional  requirements  of  particular  parts  of  NSWCDD,  with  little  data, 
function,  or  process  sharing. 

We  can  also  assess  the  central  systems  group  against  the  Software  Engineering  Institute 
(SEI)  Maturity  Framework. lo.tt  The  NSWCDD  Software  Process  Assessment  (NSPA)  Program 
has  adopted  this  approach.  NSWCDD  is  participating  in  the  Navy  Information  Systems 
Management  Center  (NISMC)  effort  to  establish  a  DoN  IRM  Assessment  Program.  NISMC  is 
developing  guidelines  to  be  used  by  DoN  organizations  in  assessing  and  measuring  their  internal 
controls  and  procedures  in  the  areas  of  IRM  and  information  Resources.  Figure  6-1  is  a  high- 
level  depiction  of  the  maturity  levels  of  the  SEI  framework.  The  goal  is  an  effective  software 
process.  An  effective  software  process  is  achieved  when  (1)  the  process  is  well-defined  and 
controlled,  (2)  the  people  are  well-trained  and  experienced,  and  (3)  the  software  tools  are 
efficient  and  effective.  We  recognized  from  the  onsets  that  the  processes  used  to  develop  and 
maintain  software  within  the  new  division  would  need  to  be  changed  and  that  we  did  not  have  the 
proper  skills  mix  to  support  new  methodologies.  IE,  using  integrated  CASE  tools  was  chosen  as 
the  process  to  be  used.  Project  management  across  the  entire  program,  using  automated 
systems,  was  initiated.  A  large  training  program  was  begun  to  update  the  skills  of  the  people  in 
the  new  techniques.  A  special  project  was  initiated  to  test  the  new  processes  and  refine  them  for 
our  use.  The  goal  was  to  examine  the  proposed  process  by  developing  a  live  application  needed 
by  NSWCDD.  Refinement  of  the  processes  is  still  going  on  as  more  groups  use  the  newer 
methodologies.  The  project  management  is  still  being  shaken  down.  We  are  researching 
configuration  management  for  a  CASE,  data  administration,  and  repository  environment. 
Basically,  we  are  trying  to  move  from  level  one  to  level  three  while  getting  the  program  into 
full  swing. 


6.2  Recommended  Information  Management  Role  and  Structures 

What  is  needed  is  a  methodology  that  stresses  data  and  process  sharing  and  an 
organizational  infrastructure  that  will  ensure  that  Information  Systems  products  developed  for 
NSWCDD  use  are  quality  ones  that  cfirectly  support  the  goals  of  the  entire  enterprise. 
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Maturity  Level 

Characteristic 

Key  Challenges 

5 

OtMbnizing 

Improvenwnt  fed  back 

Into  process 

0  Still  human  intensive  process 
o  Maintain  organization  at 
optimizing  level. 

4 

Managed 

(Quantitative) 

Measured  process 

o  Changing  techndogy 
o  Problem  analysis 

0  Problem  prevention 

3 

Defined 

(Qualitativs) 

Process  dsfin^  arfd 
Institutionalizad 

o  Process  measurement 
o  Process  analysis 
o  Quantitative  quality  plans 

2 

Repeatable 

(Intuitive) 

Process  dependent 
on  individuals 

0  Training 

o  Technical  practice 
o  Process  focus 

1 

Initiat 

(Ad  hoc  and  chaotic) 

o  Project  management 

0  Project  planning 
o  Configuration  management 

0  SofNwe  quality  assurance 

Figure  6-1.  SEI  Maturity  Framework 


An  IE  methodology  will  be  used  to  define,  develop,  deploy  and  support  elements  of  the 
NICCS.  The  IE  methodology  is  a  Systems  Engineering  methodology  for  data-driven  systems.  It 
proceeds  from  the  enterprise  level  models  in  this  ISP  to  development  of  corporate  database(s) 
and  individual  systems  for  the  enterprise's  business  needs.  The  methodology  stresses  corporate 
data  and  re-engineered  processes.  It  is  partfouiarty  good  in  assuring  that  products  will  be 
precisely  defined  and  developed  with  a  corporate  view.  An  infrastructure  to  support  the  full 
information  system  life  cycle  must  ensure  quality  procfocts  and  services  that  are: 

a  fully  tested 

b.  accurate 

c.  reliable 

d  precisely  defined 

e.  controlled 

f.  maintainable 

g.  confined  to  the  minimal  feasible  number  of  separate  configurations 

h.  safe  and  secure 
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To  do  this  the  infrastructure  will  incorporate  the  specific  engineering  disciplines  of 
Configuration  Management,  DA.  Quality  Assurance.  System  Usability  (Human  Factors),  and 
Safety,  and  Security.  It  must  also  support  facilities  management,  tools,  research,  component 
acquisition,  and  training  and  must  do  this  to  serve  a  decentralized  development  and  support  work 
force. 


Currently,  the  majority  of  the  development  work  on  business  systems  is  being  done 
within  the  Systems  Division.  Over  time,  this  will  change.  Information  systems  personnel 
resources  will  exist  throughout  NSWCDD.  Specification  development  will  be  haridled  within  the 
organizations  that  best  understand  the  function  being  automated.  In  time,  NICCS  clients  will  also 
design  and  develop  required  sub-systems.  The  Systems  Division  will  provide  program 
management  and  systems  engineering  expertise  for  systems  integration,  facilitation,  and 
management  control  over  NSWCDD’s  information  systems  investment.  By  providing  clients 
with  policies,  standards,  and  easy-to-use  devefopment  tools,  the  development  of  applications 
will  transition  to  customers. 


6.3  Overall  Organizational  Impact 

The  NICCS  Program  wilt  change  the  way  information  systems  are  managed,  engineered, 
designed,  developed,  deployed,  and  maintained  at  NSWCDD.  ^me  of  the  change  will  be  immediate 
and  some  will  evolve  over  the  next  five  years.  The  following  items  are  those  currently 
anticipated. 

First,  in  order  for  NSWCDD  managers  to  gain  trust  in  the  quality  of  the  information 
presented  to  them,  data  will  be  managed  as  a  NSWCDD  resource.  As  such,  access  to  this  resource 
will  be  established  through  NSWCDD  DA.  The  data  will  have  specific  definitions  and  naming 
conventions;  i.e.,  the  same  piece  of  data  will  not  be  called  by  different  names  in  different 
systems.  Security,  edit  criteria,  and  update  requirements  will  be  well-defined  and  published. 
Data  custodial  responsibilities  will  reside  in  individual  organizations  having  cognizance  over 
specific  data;  e.g.,  the  Comptroller  has  fiduciary  responsibility  for  financial  data.  The  NICCS 
program  will  facilitate  the  process  by  synthesizing  individual  organizational  views  into 
NSWCDD-wide  views  that  identify  interrelationships  of  data  between  organizations. 

Second,  standards  that  support  the  NICCS  development  methodology  and  that  provide  a 
common  development  infrastructure  will  be  identified  early  in  the  life-cycle.  All  development 
and  maintenance  teams  will  adhere  to  the  standards.  The  Systems  Division  will  develop  system 
usability  standards  and  enforce  their  use.  The  system  usability  standards  address  client 
interaction  with  NICCS  systems  and  facilitate  information  sharing  and  lessened  training  and 
support  costs.  Standards  for  off-the-shelf  application  software  tools  will  be  adopted. 

Third,  NICCS  will  be  the  official  information  repository  of  NSWCDD.  Information  that  is 
presented  to  Command  or  to  external  organizations  must  be  consistent  with  the  official 
information. 
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Fourth,  clients  will  be  involved  heavily  in  the  design  and  development  of  systems. 
Participation  by  representative  clients  produces  better  systems  more  quickly.  Such  systems 
are  better  accepted  by  the  total  client  community.  Figure  6-2  is  a  schematici2  of  the  system 
design  synergy  which  results  when  clients  are  involved.  Systems  that  cross  organizational  lines 
are  not  owned  by  an  individual  department.  Product  control  mechanisms  will  assure  that  all 
cognizant  organizations  are  part  of  the  decision  making  process  regarding  the  systems. 

Fifth,  traditional  roles  will  change  as  data  entry  and  access  points  change.  Data  entered 
once  will  support  a  variety  of  functionalities,  information  will  be  available,  at  appropriate 
times,  for  client  demand  access.  Clients  will  have  a  variety  of  mechanisms  by  which  they  can 
access  authorized  information.  These  mechanisms  will  range  from  standardized  reports 
distributed  on  a  prescribed  schedule  to  ad  hoc  query  support  for  seeking  display  of  real-time 
data  online.  A  client  service  operation  will  provide  ad  h^  and  custom  reporting  support  for 
those  clients  with  information  requirements  but  who  have  no  real  need  to  become  proficient  in 
data  access  methods. 

Last,  real-time  manipulation  of  reusable  data  will  minimize  the  effort  to  respond  to  data 
calls;  i.e.,  fire  drills.  Generally,  the  majority  of  data  calls  involve  looking  at  the  same  data  in  a 
slightly  different  way.  By  having  the  complete  pool  of  accurate,  up-to-date  data  accessible  as 
needed,  we  can  attain  the  desired  view  of  the  data. 


6.4  Concluslom  for  Measures  to  be  Taken 

A  support  in'rastructure,  that  ensures  that  information  system  products  for  NSWCDD 
use  are  quality  ones  that  support  the  entire  enterprise,  will  be  put  in  place  for  NICCS.  This 
will  be  accomplished  in  two  stages.  Initially,  a  Systems  Division  infrastructure  will  be  formed 
as  shown  in  Figure  6-3.  This  infrastructure  enoorr^sses  the  engineering  disc^ines 
necessary  to  ensure  quality.  They  will  be  in  place  to  support  the  accomplishment  of  the  initial 
tasks  defined  in  the  information  Strategy,  as  presented  in  Chapter  7. 

When  the  requirements  for  the  NSWCDD-wide  Information  Management  infrastructure 
are  known,  a  more  permanent  infrastructure  can  be  evolved  to  fulfill  the  requirements.  These 
requirements  will  come  out  of  the  analysis  of  the  Information  Management  Business  Area.  They 
will  change  the  scope  of  infrastructure  needs  from  what  is  needed  by  the  Systems  Division  to 
accomplish  tasks  to  the  needs  of  NSWCDD  to  manage  all  of  its  information  systems  -  both 
manual  and  automated.  This  infrastructure  will  undoubtedly  contain  the  same  disciplines  but 
will  need  to  address  NSWCDD-wide  programmatic  and  control  issues. 
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Figur*  6*2.  System  Design  with  Ciient  Psrticipstion 
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Figur*  6-3.  Information  Managamant 
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CHAPTER  7 

INFORMATION  STRATEGY 


The  ISP  has  specified  a  very  large,  complex,  and  highly  interrelated  model  to  be  used  for 
information  technology  system  development.  The  model  reflects  the  complexity  and  flexibility 
under  which  NSWCDD  operates.  The  information  strategy  should  be  driven  by  business  needs. 

To  meet  the  business  needs  will  require  that  strategies  aiso  be  pursued  to  assess  and  implement 
a  technologically  effective  infrastructure.  The  largest  business  drivers  are  as  follows: 

a  need  to  lower  NSWCDD  operating  costs 

b.  large  administrative  burden  on  line  management  and  technical  staff 

c.  non-compliant  financial  management  system 

d.  DoD  CIM-mandated  systems  looming 

e.  multiple  sites  needing  to  share  information 

f .  lack  of  coordinated  data 

g.  less  functionality  in  office  automation  than  desirable 

These  drivers  combine  in  different  ways  to  direct  which  business  areas  should  be  analyzed  first 
and  which  information  organization  strategies  are  required  immediately.  The  strategies  below 
are  fairly  risky  and  wili  tax  the  abilities  of  the  Systems  Division  to  proceed  on  such  a  broad 
front.  The  political  situation  and  environment  of  NSWCDD  and  the  NICCS  program,  however, 
drives  us  to  this  course  of  action.  There  is  a  risk  of  slipped  deadlines.  If  not  too  delayed,  the 
damage  may  not  be  too  bad  as  the  CIM  and  NAVSEA  efforts  may  also  not  meet  their  schedules.  CIM 
is  behind  its  objectives  at  this  time  because  they  were  also  pursuing  a  very  aggressive  course  of 
action.  There  is  a  large  risk  of  funding  being  cut  to  the  program.  The  result  of  deep  cuts  would 
be  the  inability  to  carry  out  these  directions  and  the  consequential  inability  of  NSWCDD  to  be 
relieved  of  the  severe  productivity  deterrents  represented  by  the  drivers. 

The  strategy  has  been  formulated  for  the  first  steps  and  is  discussed.  When  these  efforts 
are  completed,  the  next  steps  will  be  determined.  The  voiatility  of  the  environment  makes 
setting  direction  for  the  longer  course  ludicrous.  We  have,  and  will  continue,  to  pursue  the 
course  that  makes  best  sense  for  NSWCDD  while  adjusting  to  external  drivers. 


7.1  Focus  on  Finance 

We  will  follow  a  focused  effort  in  the  Business  System  area.  A  focused  effort  is  needed 
because  of  the  extreme  pressure  of  drivers  a,  b,  c.  and  d.  The  focused  effort  will  include  the 
Financial  Management  area  and  that  part  of  the  Planning  &  Review  area  that  involves  financial 
data.  This  is  a  risky  (flrection  to  take  but  is  necessary  because  of  time  constraints.  NSWCDD 
must  be  able  to  define  ns  information  and  process  requirements  in  this  area  before  CIM 
furnishes  financial  systems  to  do  the  financial  transaction  processing.  Without  the  NSWCDD 
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requirements,  we  would  be  unable  to  effectively  respond  and  implement  those  systems.  If  CIM 
does  not  produce  a  financial  system,  we  must  still  pursue  this  direction  because  of  the  non- 
compliant  status  of  the  current  financial  management  system. 

This  is  a  risky  direction  to  take  because  the  Financial  Management  area  is  the  largest  and 
most  politically  charged  of  the  Business  System  areas.  Since  we  have  never  done  a  full-blown 
BAA  before,  we  are  on  a  learning  curve.  We  will  employ  outside  consultants  to  help  us  learn 
and  to  perform  quality  assurance  on  the  BAA  models.  If  we  make  some  ’mistakes”,  the  results 
would  not  be  terrible  because  the  results  of  a  BAA  are  usually  modified  somewhat  in  the  follow- 
on  business  system  development  activities.  The  whole  IE  approach  is  one  of  modifications  of  the 
models  at  all  levels  as  both  the  enterprise  itself  changes  and  new  approaches  to  business  in 
response  to  outside  influences  is  made.  The  OoD  CIM,  DoN,  and  NAVSEA  efforts  will  probably 
require  adjustments  to  be  made  also;  e.g.,  new  requirements  for  reporting  or  tracking  are 
placed  on  activities  by  parent  organizations  because  the  ability  would  then  exist  to  track  and 
report  the  information.  The  bigger  risk  is  in  the  political  arena  within  NSWCDD  if  the  analysis 
points  to  different  organizational  structures,  sizes  and  roles. 


7.2  Creative  Corporate  Data  Development 

We  will  move  out  of  the  normal  IE  methodology  and  pursue  the  development  of  the  CDB  in 
parallel  with  the  focused  effort.  The  CDB  is  the  logical  database  containing  all  of  the  business 
data  of  NSWCDD.  Normally,  the  BAAs  define  the  data  needs.  We  will  attempt  to  build 
preliminary  databases  comprised  of  data  elements  already  found  in  some  existing  systems.  We 
are  taking  this  tack  because  of  drivers  a,  b,  d.  and  f.  This  effort  will  also  focus  on  financial  data 
initially. 

While  the  ISP  effort  was  in  progress,  we  had  another  project  underway.  This  project 
dealt  with  the  reverse  engineering  of  the  current  financial  management  system  files  and 
programs.  This  preliminary  work  is  the  beginning  point  for  this  effort.  That  information  will 
be  used  to  define  new  logical  and  physical  databases  for  a  relational  database  environment. 
Programs  to  extract  and  move  data  from  the  old  system  to  the  new  databases  will  be  developed. 
As  the  focus  effort  in  the  Financial  Management  BAA  evolves,  modiFications  will  be  made  to  the 
CDB  to  reflect  the  actual  data  needs  and  definitions.  It  is  believed  that  more  requirements  for 
data  exist  than  are  satisfied  in  the  current  Financial  Management  system. 

The  CDB  effort  will  be  involved  in  more  than  the  data  requirements  of  the  Financial 
Management  BAA.  As  was  seen  by  the  diagrams  and  charts  in  Chapter  4,  every  business  area 
updates  or  reads  data  from  many  other  business  areas.  In  particular,  data  stores  from  the 
Organization  Management  and  Product  Development  business  areas  win  need  to  have  skeleton 
databases  developed.  The  principal  data  requirements  for  Organization  Management  were 
automated  several  years  ago.  The  CHRIS  was  developed  for  the  Human  Resource  Department  and 
is  based  on  relational  database  technology.  It  will  form  the  basis  for  the  supply  of  personnel 
and  organizational  information  needed  for  the  Financial  Management  business  area.  Data  extract 
programs  wil  need  to  be  devetoped  between  CHRIS  and  the  CDB.  Of  course,  eventually,  CHRIS 
databases  will  become  a  part  of  the  CDB.  Skeleton  databases  for  the  other  data  needs  wiH  be 
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defined  and  populated,  pending  proper  definition  at  a  later  time.  Techniques  will  also  have  to  be 
developed  for  the  population  and  low-level  maintenance  of  these  skeleton  databases. 

The  principle  risk  involved  with  this  effort  is  the  possibility  of  restructuring  the  new 
databases  when  the  focused  effort  is  complete.  The  data  extract  programs  would  have  to  be 
modified  to  reflect  the  changes.  The  end  result  of  this  effort  is  positive  regardless  of  the  ability 
to  continue  with  development  in  the  Finandai  Management  business  area;  e.g.,  CIM  is  not  ready 
with  financial  transaction  processing  systems.  First,  the  definition  and  population  of  these 
databases  would  permit  any  new  requeste  or  needs  for  financial  reporting  to  be  made  from  these 
databases.  The  report  writing  would  be  done  with  better  tools  and  languages,  which  would 
permit  faster,  cheaper  generation,  and  modification  of  the  reports.  Second,  depending  on  the 
anticipated  time  lags  for  the  replacement  of  the  current  Financial  Management  system,  it  might 
be  cost-effective  to  re-engineer  programs  that  are  the  most  costly  to  maintain  now  and  move 
them  to  a  better  language  and/or  tool  using  the  new  databases.  This  technique  has  been  quite 
effective  in  many  commercial  companies  in  reducing  their  maintenance  costs  dramatically  in 
the  short  term.  Last,  the  ability  to  extract  data  from  the  CDS  to  organization-specific  financial 
systems  is  greatly  enhanced;  e.g.,  large  programs  at  NSWCDD  have  their  own  financial  tracking 
and  reporting  systems  tailored  to  sponsor  requirements. 


7 . 3  Determining  Data  Administration 

Moving  into  a  controlled  information  environment  requires  the  establishment  of  a  DA 
function.  This  is  the  principle  infrastructure  media  for  effecting  the  proper  environment  for 
information  management  and  the  coordinated  development  of  information  systems.  In 
particular,  drivers  a,  b,  d,  e,  and  f  strongly  support  this  strategy.  This  effort  is  related  to 
driver  d  because  the  function  is  the  focal  point  for  the  DA  efforts  being  done  within  DoD  by  CIM 
and  DoN  to  standarrfize  data  element  names  and  definitions  across  all  business  systems  within 
OoO.  Any  systems  we  develop  would  be  required  to  follow  these  naming  conventions. 

DA  deals  with  the  management  and  control  of  data  as  an  enterprise  asset.  It  includes 
strategic  information  planning,  data  modeling,  logical  database  design,  and  the  establishment  of 
standards,  policies,  and  procedures  for  the  care  and  feeding  of  data;  e.g.,  ownership,  security, 
privacy,  quality,  and  integrity.  DA  leads  to  improved  NSWCDD  profitability  as  indicated  by 
Figure  7-1. 

We  will  establish  a  DA  function  at  NSWCDD.  The  functions  described  within  the  scope  of 
DA  at  NSWCDD  wfil  include:  DA  representation,  policies,  guidelines,  and  standards;  DA 
partnerships;  data  planning;  the  data  repository  and  configuration  management;  compliance 
with  DA  policies  and  standards;  and  DA  measurement  of  program  effectiveness.  These  functions 
are  consistent  with  the  DoD  and  DoN  DA  guidelines,  directives,  and  implementation  procedures. 
The  DA  function  will  be  performed  by  employees  and  organizations  all  across  NSWCDD.  The  DA 
staff  within  the  Systems  Division  will  coordinate  and  guide  these  activities  and  will  perform 
some  functions  only  themselves;  e.g.,  model  management  for  the  NICCS  program. 
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Higher  Productivity 

0  Faster  application  deveioptnent 

0  Ijower  maintenance  activity 

o  Direct  client  involvement  in  appiication  creation 

0  Application  of  more  immediate  value  to  client 

Better  Information  for  Decision-making 

o  Flexible  access  to  all  NSWCDD  information 
o  Up-to-date  information 

o  Ability  to  retrieve  management  information  quickly 
o  Correlation  of  information  from  different  sources 

Greater  Responsiveness  to  Computer  Users 

o  Report  generation  without  conventional  programming 

0  Fast  responses  to  new  requests  for  information 

0  Client  capability  to  extract  the  information  they  need  when  they  need  it 

Figure  7-1.  Why  Data  Administration? 


7.4  Implications  for  Information  Management 

The  establishment  of  the  DA  function  will  not  solve  the  information  problems  of  NSWCDD 
by  itself.  DA  is  a  piece  of  the  bigger  infrastructure  and  services  needed  to  manage  information 
at  NSWCDD.  The  proper  management  and  use  of  information  at  NSWCDD  would  produce  the 
biggest  benefit  to  NSWCDD  -  more  than  financial  managentent.  NSWCDD  as  an  R&D  center  is 
in  the  knowledge  business.  We  take  information  and  transform  it  into  services  or  products. 
Being  able  to  access  and  use  information  effectively  is  the  key,  therefore,  not  only  to  the  proper 
functioning  of  our  business  processes  but  also  to  our  producing  products  and  services.  Lack  of 
automation  support  for  collaboration  inhibits  our  ability  to  make  teams  of  people  across  sites. 
Lack  of  automation  support  for  the  survey  of  outside  information  on  developments  in  our  areas 
of  business  increase  the  time  it  takes  our  personnel  to  stay  abreast  of  their  technical  fields  and 
increase  the  risk  of  missing  a  vital  piece  of  information  that  might  make  a  breakthrough 
possible.  Lack  of  coordinated  data  to  respond  to  outside  fire  drills  drains  the  time  of  our  line 
managers  from  technical  leadership  efforts.  The  list  is  quite  long.  Defining  good  information 
management  is  critical  to  the  solutions  for  drivers  a.  b.  e,  f,  and  g. 

The  analysis  of  the  Information  Management  (IM)  business  area  is  the  most  difficult 
technically  of  afi  of  the  business  areas  and  fo  tightly  intenwoven  with  ail  other  work  stemming 
from  the  ISP.  The  IM  business  area  wM  be  difficult  to  perform  because  its  analysis  does  not 
completely  follow  the  normal  IE  methods  because  its  goal  is  more  than  the  definition  and 
development  of  systems.  Part  of  the  IM  work  is  the  identification  of  tools  and  technologies  to  be 
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employed  in  the  care  arKi  feeding  of  information  identified  in  other  business  areas.  However,  the 
identification  of  these  tools  and  technologies  will  help  determine  the  direction  pursued  in  the 
other  efforts  -  even  to  the  extent  of  suggesting  information  that  could  be  created.  We  are  left 
with  a  circular  problem  and  a  technology  that  moves  extremely  rapidly.  The  IM  business  area 
enables  the  other  business  areas  to  proc^  in  a  coordinated  and  effective  manner.  The  outcome 
of  this  effort  will  define  the  infrastructure  required  for  the  life  cycle  of  all  the  systems  to  be 
developed  and  also  will  define  senrices  and  functions  needed  to  handle  the  various  types  of 
information  used  at  NSWCDD  regardless  of  the  form.  This  tatter  outcome  provides  the  rationale 
for  making  decisions  about  the  technical  architecture  and  permits  the  evaluation  of  new 
technologies  applicability  to  NSWCOO  problems. 


7.5  Towards  a  Technical  Architecture 

The  current  architecture  at  NSWCDD  will  not  permit  the  effective  IM  and  handling  of 
even  our  currently  known  requirements.  We  will  pursue  migrating  towards  a  new  architecure 
consistent  with  the  NAVSEA  direction  as  laid  out  in  Chapter  5  and  with  our  needs.  The  IM 
business  area  activity  will  help  define  functional  requirements  for  information  handling,  which 
would  need  to  be  supported  by  the  technical  architecture.  We  will  set  up  a  simulation 
laboratory  to  be  able  to  perform  hands-on  analysis  of  promising  technologies  and  to  perform 
sizing  and  performance  studies  of  existing  components  and  to  evaluate  options  for  reconfiguring 
the  current  architecture.  We  will  establish  a  network  modeling  system  to  analyze  future  loads 
on  the  networks  before  systems  are  developed.  Network  loading  may  influence  the 
implementation  approach.  We  have  atrea^  determined  that  some  of  the  existing  platforms  will 
not  be  appropriate  from  a  performance  and  maintenance  perspective  in  the  future.  Migration 
plans  will  be  developed  as  the  requirements  began  to  emerge  from  the  other  efforts.  The  first 
risk  to  technical  architecture  maintenance  and  migration  is  money  for  capital  equipment.  The 
second  risk  is  timeliness  because  of  the  gap  between  identifying  the  needs  precisely  enough  to 
justify  and  get  permission  to  procure  and  the  actual  delivery  time. 

We  will  need  to  study  and  develop  techniques  for  secure  processing  m  a  distributed 
environment.  We  have  performed  preliminary  work  in  this  area.  Since  much  of  the  work  at 
NSWCDD  is  classified,  there  is  a  need  to  be  able  to  share  classified  information  between  sites  for 
collaboration  using  electronic  means.  We  will  need  to  study  and  develop  strategies  for 
distributed  data/information  processing.  The  driver  for  this  was  discussed  in  Section  2.2.5. 

We  will  need  to  study  and  develop  techniques  for  data  integration  for  two  reasons.  First,  such 
techniques  are  required  if  we  are  to  move  forward  through  the  end-user  computing  stages  as 
was  discussed  in  Section  2.3.  Second,  it  is  most  probable  that  we  will  not  have  control  over  the 
transaction  processing  systems  but  will  receive  them  from  CIM  either  as  systems  to  run  here 
or  systems  to  which  we  will  need  to  ship  our  data.  In  either  case,  data  exchange  will  be  needed 
between  these  systems  and  our  corporate  database. 

Through  the  initial  period  we  will  attempt  to  make  do  with  the  existing  hardware 
platforms,  although  we  will  upgrade  the  capabilities  of  some  of  them.  We  would  like  to  acquire  a 
database  machine  to  host  the  larger  databases,  which  may  only  be  handled  mariginaDy  by  the 
existing  platforms.  We  will  perform  some  sizing  studies  of  our  existing  platforms  to  determine 
maximum  numbers  of  concurrent  database  end  users  who  ooukJ  be  workirtg  in  different  modes; 


7-5 


NSWCDD/TR-92/47 


e.g.,  read-only  versus  update  and  read.  We  will  also  assess  the  capabilities  of  some  of  our 
platforms  to  be  servers  in  a  new  office  automation  approach.  We  have  already  performed 
preliminary  studies  of  the  size  PC  that  would  be  required  in  the  future  office  automation 
environment.  NSWCDD  has  a  large  investment  in  PCs  and  workstations.  We  want  to  preserve 
that  investment  as  much  as  possible.  Upgrades  of  the  tower  power  level  PCs  will  probably  be 
necessary.  Of  course,  since  a  new  office  automation  approach  would  not  be  in  place  for  awhile, 
the  natural  attrition  of  PCs  may  reduce  the  scope  of  the  upgrade  problem.  . 
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CHAPTER  8 
PROGRAM  PLAN 


The  Program  Plan  has  been  developed  only  for  the  near  term.  We  can  postulate  longer 
term  strategies,  but  the  volatility  of  the  environment  may  even  change  the  strategies.  Figure 
8-1  shows  the  Program  Plan  through  FY93.  It  supports  the  Information  Strategy  given  in 
Chapter  7.  Not  shown  on  the  Program  Plan  is  the  work  involved  in  establishing  and  maintaining 
the  DA  function  or  the  configuration  management  and  quality  assurance  functions. 

We  are  conducting  the  analysis  in  the  Financial  Management,  Planning  &  Review  and  IM 
business  areas.  The  analysis  for  the  Planning  &  Review  area  will  be  primarily  concerned  with 
the  planning  data  used  in  the  financial  arena.  Undertaking  three  BAAs  simultaneously  is  risky 
with  respect  to  schedule  and  the  learning  curve  is  hard  to  estimate;  but,  during  the  ISP  effort, 
we  did  run  the  BAA  process  for  an  application  development  and  have  a  better  understanding  of 
both  the  IE  process  and  how  to  accommodate  the  culture  of  NSWCDO. 

When  these  BAAs  are  completed,  we  are  projecting  going  into  the  Acquisition 
Management,  Organizational  Management,  and  Fadlities  Management  business  areas.  The 
consolidation  is  requiring  a  hard  look  at  how  we  can  support  the  remote  locations  from  the 
Dahlgren  site  -  in  particular  support  the  White  Oak  site  because  support  personnel  were  not 
in  the  manpower  count  for  the  drawdown  there.  The  processing  and  tracking  of  acquisition 
requests  (stubs)  electronically  would  be  a  welcome  capability.  The  Organizational  Management 
business  area  contains  the  entity  types  read  and  updated  by  most  of  the  other  business  areas.  It 
is  being  sequenced  here  to  reduce  reworking  of  the  business  systems,  which  are  scheduled  to 
begin  development  in  the  same  time  frame  as  the  beginning  of  this  BAA.  The  movement  of  people 
to  the  Dahlgren  site  and  the  expansion  of  employees  there  will  make  Facilities  Management 
another  important  area  to  consider.  MILCON  constructions  and  refurbishing  of  existing 
buildings  are  in  the  plans  and  a  system  to  accurately  plan  and  track  the  work  and  the 
perturbations  of  people  space  is  seen  as  being  beneficial. 

In  parallel  with  the  BAAs  mentioned  above  will  be  work  on  the  CDB  discussed  in  Chapter 
7  above.  The  plan  follows  the  strategy  of  providing  financial  data,  followed  by  data  related  to 
personnel,  including  organizational  related  data.  We  would  then  move  toward  integrating  the 
data  requirements  from  the  Organizational  Management  and  Facilities  Management  BAA,  which 
should  be  completed  by  the  start  of  phase  2  of  the  COB  work. 

In  the  Technical  Architectures,  area  we  will  be  studying  and  then  trying  to  implement  a 
scheme  for  an  electronic  mail  facility,  in  particular.  With  the  consolidation,  came  more  sites 
with  their  own  networks.  In  addition,  there  is  a  need  to  easily  connect  to  external  systems  such 
as  the  parent  organizaticn.  Even  within  the  current  NSWCOD  environment,  there  are  PC-based 
LANS,  which  sen/e  workgroups,  either  programs  or  line  organizations.  Although  most  of  the 
electronic  mail  interchange  within  a  work  group  stays  within  the  work  group  (estimates  are 
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usually  80%),  some  messages  would  need  to  go  external  to  the  work  group.  It  is  not  effective 
nor  efficient  to  have  that  work  needing  to  leave  the  work  group  redone  on  the  centrally 
controlled  office  automation  system. 

On  the  Program  Plan  we  have  indicated  the  beginning  of  the  development  of  systems  for 
the  Financial  Management  business  area.  Three  things  need  to  be  said  about  that  line  on  the  plan 
and  longer  term  strategy  for  the  development  work.  First,  in  Figure  4-8  the  processes  were 
laid  out  by  Business  Area  and  type  of  work  that  they  did;  e.g.,  transaction  processing  or  support 
of  strategic  decision-making.  We  believe  that  the  CIM  program  will  provide  us  with  the 
transaction  processing  systems  and,  in  all  likelihood,  we  will  be  prevented  from  developing  our 
own  transaction  processing  systems.  For  example,  civilian  payroll  is  scheduled  to  be  processed 
at  central  OoO  sites,  and  all  travel  requests  are  following  a  similar  path.  The  CIM  systems  may 
flow  into  the  area  of  monitoring  and  control  also  so  that  roll-ups  and  consolidations  of  data  by 
higher  echelons  can  be  performed.  We  will  probably  be  most  concerned  with  implementing 
systems  supporting  the  other  two  types  of  processing;  i.e.,  in  support  of  planning'  and  analysis 
and  in  support  of  strategic  decision-making.  Second,  NSWCDD  currently  has  a  non-compiiant 
financial  management  system.  We  cannot  wait  too  long  even  for  the  basic  transaction  processing 
system.  Lastly,  the  first  stage  of  the  development  process  is  the  design  of  the  systems  based  on  a 
further  refinement  of  the  business  area  analysis.  We  may  need  to  perform  the  top-level  design 
of  the  transaction  processing  systems  also  just  so  we  can  more  easily  understand  where  and  how 
the  mandated  systems  fit  into  our  information  strategy  plan,  corporate  systems,  and  corporate 
databases.  At  a  minimum,  we  will  need  to  know  how  the  data  from  the  mandated  systems  will 
interface  with  the  CBO. 
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APPENDIX  A 

DETAIL  FUNCTIONAL  DECOMPOSITION 


The  Functional  Decomposition  presented  in  this  appendix  represents  the  ISP  detailed 
functional  decomposition  work.  These  diagrams  combine  the  process-to-process  relationships 
with  the  process-to-entity  type  relationships  in  a  pictorial  form  which  is  easy  to  read.  The 
diagrams  were  used  to  validate  the  models  contained  in  the  CASE  tool.  Some  supplementary 
information  which  addresses  the  syntax  and  semantics  of  this  diagramming  is  provided  here  to 
assist  you  in  understanding  the  diagrams. 


Definition  of  Function  and  Process 

Functions  and  processes  are  simply  the  activities  that  an  enterprise  needs  to  perform  to 
carry  out  its  mission.  Functions  are  made  up  of  processes  by  definition.  The  emphasis  in  the 
analysis  was  placed  on  'Vrhat''  NSWCDD  does  and  not  *who*  does  it.  even  though  the  diagrams  may 
suggest  which  current  organization  performs  the  function.  This  purely  functional  view  allows 
opportunities  for  process  improvement  and  data  sharing  from  a  neutral,  non-parochial  point  of 
view. 


The  decomposition  of  the  functions  do  not  imply  levels  of  an  organization.  For  example, 
resource  planning  could  be  done  at  any  management  level.  It  is  important  to  not  associate 
organizations  or  management  levels  with  functions  and  processes  at  this  time.  Entering  the 
TQM/TQL  world  should  dramaticaily  change  where  and  who  performs  functions  and  processes. 

The  basis  for  this  analysis  is  that  all  functions  are  a  delegation  of  management  - 
principally  line  management.  An  enterprise  may  choose  to  organize  some  of  its  functions  to  take 
advantage  of  volume  processing.  Another  example  would  be  for  greater  effectiveness  because 
some  function  required  detailed  fiduciary  understanding;  e.g.,  finance  or  personnel.  Again,  we 
must  remember  that  current  organizational  structure  may  not  be  the  best  organization  to  carry 
out  the  functions  of  NSWCDD  when  viewed  in  totality  and  not  in  vertical  slices  matching  the 
vertical  nature  of  the  DoN  structure. 
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Definition  of  Entity 

Entities  are  simply  the  things  that  an  enterprise  needs  to  keep  information  about. 

Entities  can  be  persons,  places,  things,  concepts,  events,  etc.  that  have  some  meaning  and 
importance  for  the  enterprise.  Entities  can  be  categorized  into  entity  types  and  thought  of  as 
particuiar  occurrences  of  an  entity  type.  For  example,  if  ORGANIZATION  was  modeled  as  an 
entity  type,  then  the  entity  ENGINEERING  AND  INFORMATION  SYSTEMS  DEPARTMENT  might  be  a 
single  occurrence  of  that  entity  type. 


Definition  of  Relationships 

In  the  diagrams  that  follow,  we  represent  three  relations:  (1)  relationships  between 
functions  and  functions  or  functions  and  processes,  (2)  relationships  between  activities  and 
entities,  and  (3)  relationships  between  external  entities  and  activities. 

The  first  and  third  relationships  are  both  indicated  by  arrows  and  expressed  as  the  kind 
of  data  flow  needed  between  them.  We  modelled  our  outside  relationships  because  NSWCDD  does 
not  operate  in  a  vacuum  and,  further,  the  external  influences  on  NSWCDD  are  substantial. 

The  second  relationship  deals  with  how  an  activity  relates  to  entities.  What  the  activity 
does  to  the  entity  type  is  important  because  almost  all,  if  not  all,  entity  types  are  related  to 
nK)re  than  one  activity.  This  relationship  is  also  modelled  by  an  arrow  and  a  code  indicating 
what  the  activity  does  to  the  entity  type.  By  convention,  only  a  single  interaction  code  is 
displayed  above  the  arrow,  so  a  hierarchy  of  interactions  is  used. 

C  in  a  cell  means  the  activity  may  create,  delete,  update,  and  read  that  entity  type 

D  means  the  activity  may  delete,  update,  and  read  the  entity  type 

U  means  the  activity  may  update  and  read  Are  entity  type 

U/A  means  the  activity  needs  to  associate  information  with  the  entity  type 

R  means  the  activity  may  only  read  the  entity  type 

The  U/A  relationship  is  not  as  obvious  as  the  others.  The  best  way  to  descrfoe  it  is  to  use  an 
example.  The  process  ACCEPT  &  ALLCXATE  FUNDS  needs  to  associate  with  the  funds  the 
SPONSOR,  PROGRAM,  cognizant  ORGANIZATION  at  NSWCDD  and  which  LABOR  RATE  wil  be  used. 
These  relationships  are  represented  by  the  U/A  code. 
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Conventions  in  Reading  Functionai  Decomposition  Diagrams 

The  diagrams  use  particular  shapes  to  represent  the  items  defined  and  discussed.  These 
symbols  are  shown  below.  The  other  convention  used  is  to  show  the  activity  represented  by  the 
function  or  process  in  a  shaded  box.  Anything  occurring  outside  of  that  shaded  box  is  considered 
outside  of  the  control  range  of  the  activity,  but  with  which  it  must  interact.  These  outside 
things  might  be  real  external  ot^ects  to  NSWCDD  like  sponsors  or  might  just  be  a  function  or 
process  which  is  part  of  another  activity. 


Data  View  Name 


data  flow  with  type  of  data  exchanged 


C,D.U.U/A,R 


highest  type  of  interaction  with  entity  type 
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On  the  following  pages  the  diagrams  are  in  the  order  of  the  above  diagram  moving  clockwise 
through  the  major  blocks.  They  can  be  read  in  any  order  and  the  alphabetical  list  is  below. 


Acquisition  Management .  A-23 

Facilities  Management .  A-27 

Financial  Management  .  A  - 1 7 

Humsm  Resource  Management  .  A  - 1 2 

Information  Management .  A-31 

Organizational  Management .  A- 5 

Product  &  Service  Development  .  A  -  8 

Transport  Management  .  A-30 
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ORGANIZATIONAL  MANAGEMENT 


-5 


FadityMgt 


ORGANIZATIONAL  MANAGEMENT 
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ORGANIZATIONAL  MANAGEMENT 
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PRODUCT  AND  SERVICE  DEVELOPMENT 
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ORGANIZATION 


NSWCDD/TR-92/47 


MANAGE  FACILITIES  &  UTILITIES 


NSWCDD/TR-92/47 


A>29 


ORGANIZATm 


TRANSPORT  MANAGEMENT 


03/1  Ml 


ORGANIZATION 


NSWCDD/TR-92/47 


A-31 


FACUTYMGT 
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APPENDIX  B 

ENTITY-RELATIONSHIP  DIAGRAMMING  AND  ISP  DATA  MODEL 


The  Entity  Relationship  Diagram  (ERD)  presented  in  this  appendix  represents  the  ISP 
data  model.  Some  supplementary  information  that  addresses  the  syntax  and  semantics  of  entity 
relationship  diagramming  is  provided  here  to  assist  you  in  understanding  the  ERD. 


Definition  of  Entity  Type 

Entities  are  simply  the  things  that  an  enterprise  needs  to  keep  information  about. 

Entities  can  be  persons,  places,  things,  concepts,  events,  etc.  that  have  some  meaning  and 
importance  for  the  enterprise.  Entities  can  be  categorized  into  entity  types  and  thought  of  as 
particular  occurrences  of  an  entity  type.  For  example,  if  ORGANIZATION  was  modeled  as  an 
entity  type,  then  the  entity  ENGINEERING  AND  INFORMATION  SYSTEMS  DEPARTMENT  might  be  a 
single  occurrence  of  that  entity  type. 

Entity  types  are  named  using  singular  nouns  and  represented  as  rectangular  boxes  in 

ERDs. 


ORGANIZATION 


Definition  of  Relatlonehip 

Relationships  can  be  thought  of  as  connections  between  entity  types  that  represent  some 
business  actton  that  occurs  in  the  real  world  and  involves  information  contained  in  the  pair  of 
connected  entity  types.  All  relationships  have  three  properties: 

name  -  describes  the  business  action  being  represented 
cardinality  -  how  many  entities  may  be  involved  in  the  action 
optionality  -  whether  the  action  is  optional  or  mandatory 
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Syntax  and  Semantics  of  Entity  Reiationship  Diagrams 

Relationships  are  represented  as  lines  between  entity  types.  The  relationship  name  and 
special  symbols  that  represent  the  cardinality  and  optionality  properties  of  the  relationship 
appear  on  the  line.  Relationships  are  read  by  beginning  with  one  of  the  entity  type  names  and 
traversing  clockwise  along  the  relationship  line  toward  the  connected  entity  type.  In  the 
example  below,  we  would  read  that  JOB  ORDER  NUMBER  is  assigned  to  ORG^IZATION  and 
ORGANIZATION  is  cognizant  of  JOB  ORDER  NUMBER. 

As  the  following  example  shows,  the  symbols  nearest  the  entity  type  boxes  represent  the 
cardinality  property  and  the  symbols  furthest  from  the  boxes  represent  the  optionality 
property. 


P - cardinality 


JOB  ORDER  NUMBER  ►o 


is  assigned  to 

1 

II 

A  UI7  ATl/MJ 

is  cognizant  of 

11 

1 

1 

1 

1 

_  -I 

The  straight  line  cardinality  symbol  means  that  only  one  occurrence  of  that  entity  type 
can  be  involved  in  the  relationship.  Reading  from  our  example,  "a  JOB  ORDER  NUMBER  is 
assigned  to  only  one  ORGANIZATION".  The  crow's  foot  cardinality  symbol  means  that  many 
occurrences  of  that  entity  type  can  be  involved  in  the  relationship.  For  example,  "an 
ORGANIZATION  may  be  cognizant  of  many  JOB  ORDER  NUMBERS". 

The  straight  line  optionality  symbol  means  that  the  relationship  is  mandatory;  e.g.  "a  JOB 
ORDER  NUMBER  must  be  assigned  to  an  ORGANIZATION".  The  circle  optionality  symbol  means 
that  the  relationship  is  optional;  e.g.  "an  ORGANIZATION  may  be  cognizant  of  JOB  ORDER 
NUMBERS".  The  meaning  of  these  symbols  is  summarized  in  the  following  diagram. 


Cardinality 

Optionality 

one  1 

optional 

O 

many  ^ 

mandatory 

1 
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APPENDIX  C 

CLUSTERED  CRUD  MATRIX 


The  CRUD  Matrix  shows  the  interactions  of  processes  to  entity  types.  The  matrix  lists 
the  lowest  level  functions  (processes)  in  rows,  the  entity  types  in  columns,  and  records  either 
a  C,  R,  U,  or  D  in  the  appropriate  cell  to  indicate  the  kind  of  interactions  that  can  take  place.  By 
convention,  only  a  single  interaction  code  is  entered  into  a  cell,  so  a  hierarchy  of  interactions  is 
used. 

C  in  a  cell  means  the  process  may  create,  delete,  update,  and  read  that  entity  type 
D  means  the  process  may  delete,  update,  and  read  the  entity  type 
U  means  the  process  may  update  and  read  the  entity  type 
R  means  the  process  may  only  read  the  entity  type 


Business  areas  are  indicated  in  this  matrix  as  the  bold  line  boxes.  These  groupings  of 
entity  types  and  processes  define  the  boundaries  of  the  BAA  projects  to  be  undertaken  in  the  next 
phase  of  the  methodology. 

The  first  thing  that  we  should  observe  about  the  matrix  is  that  it  is  not  a  very  sparse 
matrix;  i.e.,  many  of  the  ceils  contain  entries.  The  number  of  entries  falling  outside  of  a  box  for 
the  processes  and  entity  types  within  the  box  show  where  when  we  move  to  the  next  phases  we 
will  have  problems.  If  you  look  across  the  top  of  the  matrix  and  find  the  column  labelled 
PERSON  and  then  scan  down  its  column,  you  will  see  that  this  entity  type  information  is  used  by 
many  processes  and  Business  Areas.  The  analysis  of  what  information  it  would  contain  will  be 
performed  during  the  analysis  of  the  Organizational  Management  Business  Area.  Unfortunately, 
that  business  area  will  not  be  done  until  after  the  Financial  Management  Business  Area,  which 
needs  to  update  PERSON.  No  matter  which  Business  Area  we  started  with,  we  would  have  the 
same  problem.  Looking  down  the  process  column  to  the  process  labelled  REVIEW 
ORGANIZATIONAL  EFFECTIVENESS  and  then  moving  across  its  row,  we  see  the  same  problem  in 
this  axis;  i.e.,  more  than  just  the  Planning  &  Review  Business  Area  performs  this  generic 
process.  The  inter-relationship  problems  point  to  the  need  for  a  strong  DA  and  model 
management  configuration  effort.  We  can  also  expect  to  have  to  go  back  and  rework  some 
previous  business  areas  when  more  information  is  revealed  about  both  their  processes  and 
entity  types  by  later  business  area  analysis  performing  the  same  generic  processes,  but  maybe 
not  the  same  in  detail  or  the  *how.* 
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APPENDIX  D 

DATA  FLOW  DIAGRAMS 


The  Data  Flow  Diagrams  (DFDs)  presented  in  this  appendix  represent  the  ISP  Business 
Systems  Models.  Some  supplementary  information  which  addresses  the  syntax  and  semantics  of 
data  flow  diagrarhing  is  provided  here  to  assist  you  in  understanding  the  data  flow  diagrams. 


What  la  a  Data  Flow  Diagram? 

Different  business  activities  at  NSWCDD  do  not  operate  independently  of  each  other. 

There  is  a  lot  of  interaction.  For  example,  the  activity  involved  with  processing  an  acquisition 
request;  i.e.,  stub,  will  interact  with  financial  activities  to  provide  data  on  costs,  will  interact 
with  program  or  line  management  activities  to  exchange  information  on  schedules  for  delivery, 
will  interact  with  personnel  management  or  security/safety  management  activities  to  exchange 
accountability  information.  The  ISP  work  defined  Business  Areas  and  Business  Systems  within 
Business  Areas  at  a  high  level.  The  Business  Systems  are  composed  of  processes  defined  by  the 
functional  decomposition  of  NSWCDD  business.  The  ISP  also  defined  data  stores  comprised  of  one 
or  more  entity  types. 

A  DFD  shows  the  data  flow  into,  out  of.  and  between  the  business  systems  and  subsystems; 
i.e.,  activities,  defined  by  the  ISP.  They  show  how  activities  and  data  stores  interact  by  showing 
the  flow  of  actual  data  between  designated  activities  and  data  stores. 
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Conventions  in  Reading  DFDe 

The  DFDs  use  particular  shapes  to  represent  certain  items  of  interest: 


Data  View  Name 


data  flow  with  type  of  data  exchanged 


activity;  e.g..  system,  subsystem 


Data  Store  Name  data  store 


external  obiect;  e.g.,  system  or  sub-system 
outside  of  this  decomposition 


IExterruJ 
Object  Name 


c 


Activity  Name 


The  OFOs  are  arranged  in  order  of  the  decomposition.  The  first  page  wiil  show  the  top  level 
decomposition  for  NSWCDD.  Then,  each  Business  System  in  turn  is  shown.  For  each  Business 
System,  the  first  page  will  be  the  top  level  decomposition  for  the  Business  System  into  sub¬ 
systems.  Each  subsystem  then  folk^  in  order  for  that  Business  System.  In  the  subsystem 
(^ram  you  will  see  the  processes  making  up  the  subsystem  and  any  interactions  between  them 
and  the  data  stores.  You  will  also  see  any  interactions  between  the  subsystem  and  other  Business 
Systems,  which  wiil  be  represented  as  an  External  Object. 

The  DFDs  were  generated  from  the  CASE  tool.  In  printing  DFDs,  the  tool  does  word 
wrapping:  i.e.,  splits  a  word  based  on  number  of  characters  printed  out  instead  of  hyphenation 
rules.  The  word  wri^  are  not  a  mistake  in  die  models  but  only  a  printing  anomaly. 
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APPENDIX  E 

INFORMATION  NEEDS  SOURCE  DOCUMENTS  LIST 


Engineering  Department  Business  Information  Requirements  (NSWC  MP 
88-205),  Volume  I,  July  1988 

Draft  System  Specification  for  the  Electronics  Systems  Department 
Information  Resource  Management  System  (FIRMS),  April  1987 

K30  Requirements  Listing 

NSWC  Office  Automation  (NOA)  Requirements  Document 

Information  Resource  Management  Phase  II  Report  (NSWC  MP  86-193), 
October  1986 

Functional  Requirements  for  Business  Information  System  - 
Preliminary  Report,  April  1 989 

Strategic  Plan  for  Managing  Business  Information,  February  1989 

Memorandum  dated  4  November  1988,  from  U  to  E,  Sut^ect:  SLBM 
Software  Engineering  Environment  Requirements 

PEP  User  Survey 

A  STRATEGIC  PERSPECTIVE  ON  THE  FUTURE  OF  THE  NAVAL  SURFACE 
WARFARE  CENTER 

Memorandum  from  U30-AMJ  dated  28  June  1989,  Subject:  CORPORATE 
WELLNESS  INDICATORS. 

Memorandum  from  D213-CLB,  5200,  dated  3  December  1990,  Sul^ect: 
CORPORATE  TREND  INDICATORS. 
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